[Users] Releases and backporting

[Erik Schnetter]

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 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
>



-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20130130/74b4a10a/attachment.html