On 7 February 2011 19:50, Felix Meschberger <[email protected]> wrote:
> Hi, > > Just to shed some light from other projects: > > * In Jackrabbit a tag was created in anticipation of an > imminent release 2.2.3. A bug was discovered. The tag was removed > and the next release will be 2.2.4 (there will not be a 2.2.3). > > * In Tomcat they voted on a release and found issues (quality > wise) so decided to declare 7.0.7 broken. The version number was > not reused and the release currently under vote has the next > version 7.0.8. > which would actually be allowed under option A because it says "can reuse", not "must" (unlike option B) personally I think it's a bad idea to try to create a single rule to cover all possibilities - just leave it to the discretion of the release manager > Regards > Felix > > > Am Montag, den 07.02.2011, 10:56 +0000 schrieb Jeremy Hughes: > > A (non-binding). > > > > FWIW: Stuart brought me off the fence. If the first 1.0.x release is > > 1.0.5 then under semantic versioning guidelines this would mean 5 > > releases of the bundle at previous micro numbers have already passed > > which might cause users some confusion, or cause them to ask for an > > explanation. This confusion persists for ever more. The number of > > people seeing this admittedly lesser kind of confusion will likely be > > far greater than the people who use the RC artifacts from a staging > > repo, who should know better. > > > > On 5 February 2011 12:50, Stuart McCulloch <[email protected]> wrote: > > > On 5 February 2011 12:21, Guillaume Nodet <[email protected]> wrote: > > > > > >> As long has the release has not been approved, the tag does not match > > >> an official release, so it can be freely deleted. > > >> > > > > > > yep, that's what I meant - another point to consider is users might see > > > 1.0.5 and think it's stable (as it's not 1.0.0) whereas in fact there > could > > > have been 5 staged versions just to sort out license / dependency > issues and > > > no actual code changes > > > > > > Once the release is voted, I think everyone agree the tag becomes > immutable. > > >> > > >> FWIW, Git is much better as a tag really correspond to a moment in the > > >> history, not a branch (which actually makes more sense if you think > > >> about it). > > > > > > > > > agreed, git is better in this regard - but it can be hard to understand > at > > > times :) > > > > > > > > >> On Sat, Feb 5, 2011 at 11:04, Felix Meschberger <[email protected]> > > >> wrote: > > >> > Hi, > > >> > > > >> > Am Samstag, den 05.02.2011, 09:52 +0000 schrieb Sahoo: > > >> >> On Friday 04 February 2011 04:48 PM, Stuart McCulloch wrote: > > >> >> > it is easy to retag releases in svn > > >> >> > > > >> >> > > > >> >> What exactly do you mean by "retag releases in svn?" Rename an > existing > > >> >> tag or using the same tag name to tag a different snapshot of the > source > > >> >> code base? Neither should be done in my IMHO. > > >> > > > >> > Agreed, both is far too easy ... > > >> > > > >> > Regards > > >> > Felix > > >> > > > >> > > > >> > > >> > > >> > > >> -- > > >> Cheers, > > >> Guillaume Nodet > > >> ------------------------ > > >> Blog: http://gnodet.blogspot.com/ > > >> ------------------------ > > >> Open Source SOA > > >> http://fusesource.com > > >> > > > > > > > > > > > > -- > > > Cheers, Stuart > > > > -- Cheers, Stuart
