Ant, I am not sure how relevant this is, but in the context of versioning Tuscany for OSGi, Tuscany modules are being built as OSGi bundles with "real" versions (eg. the current build uses "2.0"). The version used is not currently derived from the maven version, instead it is specified independently as a property in modules/pom.xml - so it won't actually break if you modified 2.0-incubating-SNAPSHOT to SNAPSHOT. But it will become less obvious to OSGi users what version a Tuscany build really is. We will need a real version for the snapshot builds for building OSGi bundles regardless of whether we use that as the version for maven. The question is whether we need OSGi build versioning to be consistent with maven versions - OSGi users building against Tuscany 1.4-SNAPSHOT probably expect to use the 1.4 release, while non-OSGi users as you say may expect to use the latest SNAPSHOT. Anyway, I just thought I will point this out, I dont actually mind either way.
On 6/13/08, ant elder <[EMAIL PROTECTED]> wrote: > > On Tue, Jun 10, 2008 at 9:41 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > > On Sat, Jun 7, 2008 at 1:11 AM, Jean-Sebastien Delfino < > > [EMAIL PROTECTED]> wrote: > > > Luciano Resende wrote: > > >> > > >> How about 1.5-SNAPSHOT ? This would probably give us some room to have > > >> couple releases without the necessity to keep updating the trunk pom > > >> version. And this would probably make everybody happy :) > > >> > > >> On Fri, Jun 6, 2008 at 1:14 AM, ant elder <[EMAIL PROTECTED]> > wrote: > > >>> > > >>> On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende < > [EMAIL PROTECTED]> > > >>> wrote: > > >>> > > >>>> I guess part of problem here is because a lot of people assume that > > >>>> the maven artifact version represents what is going to be our next > > >>>> release and then, if it's set as 2.0-SNAPSHOT, it means our next > > >>>> release would be 2.0. > > >>> > > >>> I agree, this is exactly the issue. But I'm not sure its that much of > > an > > >>> unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT > as > > >>> the > > >>> trunk version before there has been any decision to start working on > a > > >>> 2.0 > > >>> in trunk. > > >>> > > >>> ...ant > > >>> > > >> > > >> > > >> > > > > > > I'd prefer the next logical number, 1.3 for example. > > > > > > > I still think plain SNAPSHOT would be simplest but as no one else seems > to > > like that I think I agree with this - the next logical number seems > better > > than things like 1.x or 2.0 etc. So, I plan to change trunk to > 1.4-SNAPSHOT > > when the 1.3 branch is taken, do say if you really don't like this but > its > > what we've been doing most of the time in the past so i hope most can > live > > with it. > > > > ...ant > > > > > I've been asked off list to highlight an issue that may not have been clear > from whats already been said in this thread. > > If we use 1.4-SNAPSHOT in trunk then external people who want to stay up to > date with the latest code will use that version in their dependencies. They > may not pay that close attention to the dev list so when we create the > branch for a real 1.4 release and change the trunk to 1.5-SNAPSHOT the > users > dependencies will still use 1.4-SNAPSHOT but now instead of getting the > latest code they're getting the stable branch code. One way this could be > avoided is by using a trunk version of simply "SNAPSHOT". Is anyone really > against SNAPSHOT if we went for that instead of 1.4-SNAPSHOT? > > ...ant > -- Thank you... Regards, Rajini
