[Users] Releases and backporting

[Barry Wardell]

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