Hi,
The release branches and tags have now been created. This means that every change that should make it into the release now has to be committed to this branch (in addition to possibly being committed to trunk/master). Also, the release tag should be reset in that case. These two should only differ after the release (if at all).
This also means that the development branch is now open again.
Frank
On 15 May 2015, at 20:27, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi,
The release branches and tags have now been created. This means that every change that should make it into the release now has to be committed to this branch (in addition to possibly being committed to trunk/master). Also, the release tag should be reset in that case. These two should only differ after the release (if at all).
I thought tags were immutable? They should probably only have been created at the time of release, since we don't need them for the final phase of testing.
On Fri, May 15, 2015 at 10:06:35PM +0200, Ian Hinder wrote:
I thought tags were immutable? They should probably only have been created at the time of release, since we don't need them for the final phase of testing.
No, they are not, both in svn and git. And git doesn't even track their history. I should probably have created them later - it is just convenient to do both branches and tags in one go, and I didn't expect changes at that point.
Frank
On 15 May 2015, at 22:15, Frank Löffler knarf@cct.lsu.edu wrote:
On Fri, May 15, 2015 at 10:06:35PM +0200, Ian Hinder wrote:
I thought tags were immutable? They should probably only have been created at the time of release, since we don't need them for the final phase of testing.
No, they are not, both in svn and git. And git doesn't even track their history. I should probably have created them later - it is just convenient to do both branches and tags in one go, and I didn't expect changes at that point.
I guess they should be immutable as a matter of policy rather than technicality. The use case for tags as opposed to branches is to refer to a specific version, rather than a line of development.
On Fri, May 15, 2015 at 10:40:02PM +0200, Ian Hinder wrote:
I guess they should be immutable as a matter of policy rather than technicality. The use case for tags as opposed to branches is to refer to a specific version, rather than a line of development.
I agree, in part. Immutable may be too much (everyone makes mistakes), but at least they should be part of the history. And after the release we will handle it like this: tag won't be changed.
Frank
users@lists.einsteintoolkit.org