directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
Date Wed, 05 Jan 2011 20:25:26 GMT
On Wed, Jan 5, 2011 at 10:15 PM, Emmanuel Lecharny <>wrote:

> On 1/5/11 8:08 PM, Alex Karasulu wrote:
>> On Wed, Jan 5, 2011 at 8:06 PM, Jesse McConnell
>> <>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.

>  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 ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message