I suggest to have a release branch that gets updated by backports. From time to time, we create a new point release by creating a new tag.
branch: trunk (may be unstable) branch: ET_2012_11 (may contain new backports) tag: ET_2012_11_0, ET_2012_11_1, etc. (tested, created every few weeks or after a serious error has been corrected)
The download instructions should point to tags. Creating a new point release would be a non-trivial task, since it involves tagging all repositories, running tests on multiple machines, updating web pages, writing an announcement etc.
-erik
On Wed, Jan 30, 2013 at 3:29 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
Hi,
Recently, the issue of backporting fixes to the released version of the Einstein Toolkit has come up. When the code is obviously wrong in the released version, especially when this is a newly-introduced problem, we have committed the fix both to the trunk and to the release branch. There have been a small number of these commits.
Now that I think about it, I see that this approach has some problems.
- If someone says in a paper that they are using "the release" of the ET,
there is no way to know which version they are using if "the release" refers to the branch (which can point to different versions as people commit occasional fixes). 2. There is no way to easily test the "proposed re-released version" before moving the release branches, at which point new users will be downloading the untested version.
Version control systems have both branches and tags. Branches point to "lines of development" and tags point to specific versions. In order to identify specific releases of the code, we should use tags, for example ET_2012_11.1, ET_2012_11.2 etc. Once created, these never change. Perhaps we want the following:
- Branch for trunk, as currently;
- Branch for "backports"; this would be things which people think should
be backported and which can then be checked out and tested easily;
- Tags for tested, released versions (ET_2012_11.N)
- Branch for the latest tagged version (ET_2012_11) (?)
The important thing is that people know (and can state in papers) what version of the code they are using. One way to ensure this is to ask people to check out the release from a specific tag, and then to check it out again from the new tag when there is a new version. An alternative would be to always check out from the release branch, but to provide a GetComponents mechanism for upgrading from one version to the next, and for verifying that the currently checked-out code is all from the same tag.
I don't want to overcomplicate things, but issue (1) listed above is important. Does anyone have some better suggestions?
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users