[Users] Releases and backporting

[Barry Wardell]

This post from a while back is also relevant to the present
discussion: http://lists.einsteintoolkit.org/pipermail/users/2010-June/000244.html

On Wed, Jan 30, 2013 at 12:09 PM, Barry Wardell <barry.wardell at gmail.com> wrote:
> I think it definitely makes sense to keep a better record of exactly
> what constituted a "release". The only way I can see for this to work
> is to do something like Ian suggests, ie.
>
> * When creating a new release, create a tag and branch for it.
> * Users would checkout the tag and everyone would be guaranteed that
> that tag refers to a particular version of the code which never
> changes.
> * Backports get committed to the release branch. Once all backports
> have been tested, a new point release is tagged. If necessary, this
> can happen several times.
>
> This would work fine with git and mercurial where tags and branches
> are extremely cheap, but would be a bit more of a pain for components
> stored in svn (for example: branching and tagging require a full copy
> of the entire tree, there is nothing to stop people committing on top
> of a tag, etc.) so I'm not sure if it's feasible without a lot of
> effort (at least not without switching most components to a single
> "modern" version control system).
>
> A related issue is the case where Kranc gets a backport applied. In
> that case, I think it is important to make sure that all Kranc thorns
> are also regenerated. I have just discovered that something similar
> happened in the Ørsted release, where the release version of McLachlan
> was not generated with the release version of Kranc (the very next
> commit on the McLachlan master branch after the release was branched
> was to regenerate the code using the release version of Kranc).
>
> Barry
>
> On Wed, Jan 30, 2013 at 8:29 AM, Ian Hinder <ian.hinder at 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.
>>
>> 1. 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 at einsteintoolkit.org
>> http://lists.einsteintoolkit.org/mailman/listinfo/users