On Wed, Jan 5, 2011 at 8:06 PM, Jesse McConnell
<jesse.mcconn...@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.
> 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.
I would however like to make shared libraries into bundles for the following
reasons:
(1) Helps think better about dependencies interfaces and implementations
with public and private classes (exported verse bundle private). This will
help us set solid boundaries around API's.
(2) ApacheDS 3.0 work can be begun to leverage OSGi without having to
mess around with the shared and ldap-api artifacts. The less we touch after
releasing 1.0 versions the better. The goal is not to have to manage
multiple versions of an API as Emm mentioned.
> Since you have eclipse plugins you ought to
> build those with maven + tycho and have a similar and sane versioning
> system.
>
>
I talked with Pierre about it. As a side point because of the way the build
in Studio is setup, we're unable at this point to take advantage of IDE
refactoring since dependencies are on bundle jars rather than on projects
themselves. Do you know if using Maven + Tycho will help with this specific
problem?
I'm asking this because it might spare some work for us when we refactor
shared which Studio depends on.
> 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.
>
> On Wed, Jan 5, 2011 at 11:51, Alex Karasulu <akaras...@apache.org> wrote:
> >
> > On Wed, Jan 5, 2011 at 7:49 PM, Alex Karasulu <akaras...@apache.org>
> wrote:
> >>
> >> Hi all,
> >> Let's start off with basics by discussing what our contracts are WRT
> >> API's, and releases with our users. We can throw out the past focusing
> on
> >> the future to save time since 2.0 will effectively be a new era.
> >> This 2.0 release I'm gathering is the first stable, serious, enterprise
> >> ready major release of ApacheDS. 1.0 was kind of a toy considering all
> it's
> >> faults and shortcomings so the two situations are not completely the
> same.
> >> We have to select a release scheme. Based on the scheme we select, we
> have
> >> to adhere to the rules of that scheme. This is like picking what our
> >> contract with users of the server will be for release compatibility.
> >> So when considering compatibility we have to consider several things
> >> besides just APIs and SPIs:
> >> o Database Format
> >> o Schema
> >> o Replication Mechanism
> >> o Configuration
> >> o API Compatibility
> >> o Plugins - We have pseudo plugins like Partitions, Interceptors and
> >> Handlers that users can alter which involve SPIs.
> >> So based the scheme we select we have to define policies for these
> >> interfaces. I am calling anything that is exposed to the users as
> interfaces
> >> like DB format for example. We have the following choices for schemes:
> >> 1. Milestone Scheme (Eclipse)
> >> 2. Traditional major.minor.micro Scheme
> >> 3. maj.min.mic with Odd Numbered Versions for Development Releases (Old
> >> Linux Kernel)
> >> 4. Modern Linux Versioning Scheme
> >> Se let's start off talking about which scheme we like best and why along
> >> with pros and cons taking into account realistically how we work.
> >
> > There are many more schemes out there to choose from. Feel free to add to
> > this list below.
> >
> > --
> > 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
> >
>
--
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
