On Wed, Jan 5, 2011 at 10:15 PM, Emmanuel Lecharny <email@example.com>
+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.
On 1/5/11 8:08 PM, Alex Karasulu wrote:
On Wed, Jan 5, 2011 at 8:06 PM, Jesse McConnell
1. Milestone Scheme (Eclipse)
I like this a lot. This way there's a product release version yet all
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.
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.
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.
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.
+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!
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).
building with maven the -SNAPSHOT is turned into the qualifier so we
Thanks for the input. For the record I too think #1 is the best option for
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..
us going forward.
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.
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