directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
Date Wed, 05 Jan 2011 20:15:40 GMT
On 1/5/11 8:08 PM, Alex Karasulu wrote:
> On Wed, Jan 5, 2011 at 8:06 PM, Jesse McConnell
> <jesse.mcconnell@gmail.com>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.

Something to think about, IMO.
>> 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 ?


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message