On Wed, Jan 5, 2011 at 10:15 PM, Emmanuel Lecharny <[email protected]>wrote:
> On 1/5/11 8:08 PM, Alex Karasulu wrote: > >> On Wed, Jan 5, 2011 at 8:06 PM, Jesse McConnell >> <[email protected]>wrote: >> >> 1. Milestone Scheme (Eclipse) >>> >>> to further explain that one, those are just the public versions that >>> people consume...under the hood all of the bundles follow the osgi >>> versioning convention of major.minor.bugfix.qualifier so it looks like >>> 7.2.2.v20101205 or some variation there of. >>> >>> >>> I like this a lot. This way there's a product release version yet all >> component bundles can be versioned separately. This way their releases can >> occur independently of the product to allow for updates. >> >> This sounds more granular to me. Different component bundles will change >> at >> different rates and to allow this in a manageable way is wonderful. >> > +1 too. I'm not convinced about the need to have those v<Date> stuff, but > it does not cost anything, so I buy it. > > +1 > > if you guys are targeting osgi at any point then I would recommend you >>> just stick with that scheme, similar to how we do versioning in jetty >>> which works pretty well. >>> >> >> OSGi is something we've been considering for the past 7 years :-). However >> it's definitely not something we're going to do for the 2.0 server >> release. >> > If we go for miletsones (ie 2.0-Mx), then I have no problem to try to get > OSGi injected. It may postpone the 2.0-GA release, but frankly, I don't > think it will cost a lot. Add to this that many OSGi aware peeps are ready > to give an hands here. > > +1 then let's just do a 2.0-M1 release. This is great and gets users used to the new scheme. Plus we can modify the API without flipping out - the contract is clear to users, things will change. And you get the 2.0 advancing feeling that might help get more adoption into the picture. I'm liking this a lot! > building with maven the -SNAPSHOT is turned into the qualifier so we >>> just go with 7.3.0-SNAPSHOT and so on til a release and then we go >>> with v'year'month'day...we use the v so that it sorts correct with >>> things like 7.3.0.RC0, etc.. >>> >>> Thanks for the input. For the record I too think #1 is the best option >> for >> us going forward. >> > > Question : how do we propagate the 7.3.0-xxyz versions ? Right now, > releasing is a damn complex process which costs us one week (well, let's say > 4 days if everything goes fine, vote included). > > Or is this just equivalent to a nightly build ? I really have to read this eclipse link you put up. I've never released the Eclipse way. Off the cuff with common sense I am thinking we have for example 2.0.0-M1-cmajor.cminor.cmicro for each component where the, cmajor = component major version, cminor = component minor version, and cmicro = component micro version Adjusting this in our build is easy I think. We can play with it down the line if the others agree with this new scheme. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
