Are the OSGI "real" versions required to be numeric, which would also mean 1.x wouldn't work so well as a version for OSGi right?
...ant On Fri, Jun 13, 2008 at 9:24 AM, Rajini Sivaram < [EMAIL PROTECTED]> wrote: > 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 >
