You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2009/08/11 15:04:52 UTC
[ApacheDS] How about yet another versioning scheme conversation gang?
Not like we've had enough conversations that sucked up vast amounts of our
time before on this topic. However after a conversation with Emmanuel I
think we might have to present another approach.
Current Scheme
----------------------
o We have major.minor.micro numbers.
- major number denotes massive architectural shift
- minor number denotes feature introductions
- micro number denotes bug fixes and optimizations without changes to
interfaces, db formats etc
o Minor numbers were either 0 or 5. The 5 was for experimental branches
with many big features being added across different releases in the branch.
The 0 was for stable branches where no new features were being added but
only fixes and optimizations were made.
o The 0 or 5 schema came from the even/odd schema used in the older linux
versioning scheme for the kernels before 2.6. We switched to 0/5 because we
wanted the move from 1.0 to 1.5 to mean more than a number change but to
represent the shift in JDK compatibilities. 1.5 will only run on JDK 1.5
and up.
There's some good things about this schema and some bad things.
1. The scheme used takes a long time to bring about a minor release with
"stable" feature additions.
2. Many of our 1.5 releases though were more stable than our 1.0 so this
connotation was no longer working for us.
3. The scheme was slowing us down but hopefully (not that we could measure
it) was leading to a more stable LDAP server. Not like we were building a
desktop app that can get restarted to clear out leaks and such.
4. The scheme is just strange. Going from 1.0 -> 1.5 then to 2.0 is odd.
What do we do go to 2.5 next?
5. What about nice little features that did not take time to do but must
wait for other major features to be deemed 'stable' and usable? They don't
get to the user fast enough.
I'm sure lots more can be found for and against this model. But at this
point with the 0/5 stuff is just odd lookin and hard to make sense of.
After a convo with Emm on IRC we came up with the following new scheme:
Future Scheme
--------------------
o We have major.minor.micro numbers:
- major number denotes massive architectural shift
- minor number denotes feature introductions
- micro number denotes bug fixes and optimizations without changes to
interfaces, db formats etc
o We bump up minor numbers whenever we add a new feature no matter how
many new things were added.
o We bump up micro numbers in case we make a bug fix or improvement.
The idea here is to just keep bumping organically as we like. We can for
example just go to 2.0.0-rc1 after 1.5.5. This seems like a natural
progression to get us out of this old scheme with one last .5 increment.
Then we can just keep bumping as we add feature after feature without the
requirement for micro bug fix releases. So we can have a 2.1.0 then a 2.1.1
etc or just jump to 2.2.0 from 2.1.0. Up to us. This is the cool thang
about it.
With this freedom comes benefits to our users. They get to see features
faster since we do more releases back to back. Hopefully though greater bug
introduction will not be there. But this is a balanced risk we will have to
take. So our releases will sort of be like what Atlassian does for example
for JIRA and Confluence.
Thoughts?
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Chris Custine <ch...@gmail.com>.
+1 I definitely think this will allow a faster progression of features
without having to worry about the quite loose terms "stable" and
"experimental". I think this will really help free you up to go forward at
a much more natural pace.
Chris
--
Chris Custine
FUSESource :: http://fusesource.com
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org
On Tue, Aug 11, 2009 at 7:04 AM, Alex Karasulu <ak...@apache.org> wrote:
> Not like we've had enough conversations that sucked up vast amounts of our
> time before on this topic. However after a conversation with Emmanuel I
> think we might have to present another approach.
>
> Current Scheme
> ----------------------
>
> o We have major.minor.micro numbers.
> - major number denotes massive architectural shift
> - minor number denotes feature introductions
> - micro number denotes bug fixes and optimizations without changes to
> interfaces, db formats etc
> o Minor numbers were either 0 or 5. The 5 was for experimental branches
> with many big features being added across different releases in the branch.
> The 0 was for stable branches where no new features were being added but
> only fixes and optimizations were made.
> o The 0 or 5 schema came from the even/odd schema used in the older linux
> versioning scheme for the kernels before 2.6. We switched to 0/5 because we
> wanted the move from 1.0 to 1.5 to mean more than a number change but to
> represent the shift in JDK compatibilities. 1.5 will only run on JDK 1.5
> and up.
>
> There's some good things about this schema and some bad things.
>
> 1. The scheme used takes a long time to bring about a minor release with
> "stable" feature additions.
> 2. Many of our 1.5 releases though were more stable than our 1.0 so this
> connotation was no longer working for us.
> 3. The scheme was slowing us down but hopefully (not that we could measure
> it) was leading to a more stable LDAP server. Not like we were building a
> desktop app that can get restarted to clear out leaks and such.
> 4. The scheme is just strange. Going from 1.0 -> 1.5 then to 2.0 is odd.
> What do we do go to 2.5 next?
> 5. What about nice little features that did not take time to do but must
> wait for other major features to be deemed 'stable' and usable? They don't
> get to the user fast enough.
>
> I'm sure lots more can be found for and against this model. But at this
> point with the 0/5 stuff is just odd lookin and hard to make sense of.
> After a convo with Emm on IRC we came up with the following new scheme:
>
> Future Scheme
> --------------------
>
> o We have major.minor.micro numbers:
> - major number denotes massive architectural shift
> - minor number denotes feature introductions
> - micro number denotes bug fixes and optimizations without changes to
> interfaces, db formats etc
> o We bump up minor numbers whenever we add a new feature no matter how
> many new things were added.
> o We bump up micro numbers in case we make a bug fix or improvement.
>
> The idea here is to just keep bumping organically as we like. We can for
> example just go to 2.0.0-rc1 after 1.5.5. This seems like a natural
> progression to get us out of this old scheme with one last .5 increment.
> Then we can just keep bumping as we add feature after feature without the
> requirement for micro bug fix releases. So we can have a 2.1.0 then a 2.1.1
> etc or just jump to 2.2.0 from 2.1.0. Up to us. This is the cool thang
> about it.
>
> With this freedom comes benefits to our users. They get to see features
> faster since we do more releases back to back. Hopefully though greater bug
> introduction will not be there. But this is a balanced risk we will have to
> take. So our releases will sort of be like what Atlassian does for example
> for JIRA and Confluence.
>
> Thoughts?
>
> --
> Alex Karasulu
> My Blog :: http://www.jroller.com/akarasulu/
> Apache Directory Server :: http://directory.apache.org
> Apache MINA :: http://mina.apache.org
>
>
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Stefan Seelmann <se...@apache.org>.
Hi Alex,
really +1 for your proposal.
Additional I think milestone release could also make sense.
Kind Regards,
Stefan
Alex Karasulu wrote:
> Not like we've had enough conversations that sucked up vast amounts of
> our time before on this topic. However after a conversation with
> Emmanuel I think we might have to present another approach.
>
> Current Scheme
> ----------------------
>
> o We have major.minor.micro numbers.
> - major number denotes massive architectural shift
> - minor number denotes feature introductions
> - micro number denotes bug fixes and optimizations without changes
> to interfaces, db formats etc
> o Minor numbers were either 0 or 5. The 5 was for experimental
> branches with many big features being added across different releases in
> the branch. The 0 was for stable branches where no new features were
> being added but only fixes and optimizations were made.
> o The 0 or 5 schema came from the even/odd schema used in the older
> linux versioning scheme for the kernels before 2.6. We switched to 0/5
> because we wanted the move from 1.0 to 1.5 to mean more than a number
> change but to represent the shift in JDK compatibilities. 1.5 will only
> run on JDK 1.5 and up.
>
> There's some good things about this schema and some bad things.
>
> 1. The scheme used takes a long time to bring about a minor release with
> "stable" feature additions.
> 2. Many of our 1.5 releases though were more stable than our 1.0 so this
> connotation was no longer working for us.
> 3. The scheme was slowing us down but hopefully (not that we could
> measure it) was leading to a more stable LDAP server. Not like we were
> building a desktop app that can get restarted to clear out leaks and such.
> 4. The scheme is just strange. Going from 1.0 -> 1.5 then to 2.0 is
> odd. What do we do go to 2.5 next?
> 5. What about nice little features that did not take time to do but must
> wait for other major features to be deemed 'stable' and usable? They
> don't get to the user fast enough.
>
> I'm sure lots more can be found for and against this model. But at this
> point with the 0/5 stuff is just odd lookin and hard to make sense of.
> After a convo with Emm on IRC we came up with the following new scheme:
>
> Future Scheme
> --------------------
>
> o We have major.minor.micro numbers:
> - major number denotes massive architectural shift
> - minor number denotes feature introductions
> - micro number denotes bug fixes and optimizations without changes
> to interfaces, db formats etc
> o We bump up minor numbers whenever we add a new feature no matter how
> many new things were added.
> o We bump up micro numbers in case we make a bug fix or improvement.
>
> The idea here is to just keep bumping organically as we like. We can
> for example just go to 2.0.0-rc1 after 1.5.5. This seems like a natural
> progression to get us out of this old scheme with one last .5
> increment. Then we can just keep bumping as we add feature after
> feature without the requirement for micro bug fix releases. So we can
> have a 2.1.0 then a 2.1.1 etc or just jump to 2.2.0 from 2.1.0. Up to
> us. This is the cool thang about it.
>
> With this freedom comes benefits to our users. They get to see features
> faster since we do more releases back to back. Hopefully though greater
> bug introduction will not be there. But this is a balanced risk we will
> have to take. So our releases will sort of be like what Atlassian does
> for example for JIRA and Confluence.
>
> Thoughts?
>
> --
> Alex Karasulu
> My Blog :: http://www.jroller.com/akarasulu/
> Apache Directory Server :: http://directory.apache.org
> Apache MINA :: http://mina.apache.org
>
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> On Tue, Aug 11, 2009 at 5:17 PM, Emmanuel Lecharny <el...@apache.org>wrote:
>
>
>> Alex Karasulu wrote:
>>
>>
>>> I think we're on the same page. But I would add one more caveat, that Y
>>> "tries" to maintain API compatibility but there is no guarantee.
>>>
>>>
>> Why can't we guarantee that if the API is changed, then the old API will
>> still be available, but marked as @deprecated, until the next X release ? Is
>> it too strong a constraint?
>>
>>
>
> Yeah I think it is too much. Not feeling too generous on the API front
> since it's going to see lots of flux. Don't want our hands tied like it was
> during all these 1.0/1.5 branches. I want to move faster. The faster we
> move we can come back in like 3.0 and say Y can guarantee API backwards
> compatibility.
>
Then the question is if ADS 2.0 will be considered as a stable or
unstable version. If we have to wait for 3.0 in order to guarantee the
API stability, we are putting the users in jeopardy, but much more
important, we are creating a costly task for those of us who are dealing
with maintenance.
IMHO, we don't have a hell lot of API and that should be stable soon.
Regarding the configuration and the data, offering tools to upgrade
should be enough.
And whatever mistakes we did before should not be a reason for not
considering Jesse proposal, which make a lot of sense to me.
>
>
>> There is also an aspect which is not related to the API : configuration
>> _and_ data. For Minor versions, we must guarantee a compatible
>> configuration, and a compatible dataBase, otherwise we -at least- must
>> provide teh tooling to migrate easily both of them.
>>
>> Thoughts ?
>>
>>
>
> I'm not willing to guarantee this. Technically the database format and the
> configuration format/scheme is yet another interface the user is faced with
> regarding ADS. When I say interface I mean it very broadly to include data
> formats and things like configuration.
>
So we have to go with tooling - which we have, as we can load all the
server.xml version since 1.5.2 in studio. Converting back and forth is
not that complicated.
Data conversion is a piece of cake : export LDIF, import LDIF.
> I might want to slowly migrate some configuration feature that was in the
> XML format slowly over two feature releases into ADS. If I must provide
> this guarantee then I have to wait until 3.0 to introduce these changes.
> It's not a good thing for us who really want to provide the user with what
> they really need in the end as soon as possible.
>
The core configuration is likely to stabilize soon. I really don't like
the idea of having a moving target, until 3.0. We must provide some kind
of stability or ease of use during the migrations. My vote would go
toward the second aspect (more tooling).
> We must allow for rapid progression. Like I said I will be willing to make
> the guarantee once we're in a 3.0 or 4.0. But not now. Life is hard enough
> for us already. Let's keep the load light and help users when and if there
> really are API issues in the end. But it's safer to say we provide no
> guarantee than to say that we do guarantee back compat.
>
I don't want to be stuck on the users ML for months explaining how to
migrate from version 2.0 to 2.1, if we are to release a minor every 2/3
months. The effort to put to get the migration tools is not exceeding
the time lost - and the potential users lost - in 'helping users' to
migrate.
Every time we got a mail from someone wanted to migrate from a version
1.5.X to 1.5.X+1, it was time consuming, painful, and at the end, the
user was pissed off. I don't want this scheme to be reproduced.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Jesse McConnell <je...@gmail.com>.
to comment on my own mail...
> If your plotting those sorts of changes then the thing to do is
> develop a public API that you commit to adhering to for the life of
> that branch and then you can change things behind that to your hearts
> content. But give people some semblance of stability if they plan to
> incorporate ads into their systems.
>
this does not mean you can't expose new features to the public api as
your going along, its just a commitment that you won't whack stuff out
of it I might be relying on without signaling that in the version
change
cheers,
jesse
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Jesse McConnell <je...@gmail.com>.
> Yeah I think it is too much. Not feeling too generous on the API front
> since it's going to see lots of flux. Don't want our hands tied like it was
> during all these 1.0/1.5 branches. I want to move faster. The faster we
> move we can come back in like 3.0 and say Y can guarantee API backwards
> compatibility.
>
you may want to move faster but I would personally not be keen on
working with a system that didn't make the attempt to maintain api
compat with the velocity of changes you appear to be keen on
making...no one wants to subscribe to a development track where every
2.x change is going to require an unknown amount of time invested in
tweaking to align with a new API.
If your plotting those sorts of changes then the thing to do is
develop a public API that you commit to adhering to for the life of
that branch and then you can change things behind that to your hearts
content. But give people some semblance of stability if they plan to
incorporate ads into their systems.
>>
>> There is also an aspect which is not related to the API : configuration
>> _and_ data. For Minor versions, we must guarantee a compatible
>> configuration, and a compatible dataBase, otherwise we -at least- must
>> provide teh tooling to migrate easily both of them.
>>
>> Thoughts ?
>
> I'm not willing to guarantee this. Technically the database format and the
> configuration format/scheme is yet another interface the user is faced with
> regarding ADS. When I say interface I mean it very broadly to include data
> formats and things like configuration.
>
> I might want to slowly migrate some configuration feature that was in the
> XML format slowly over two feature releases into ADS. If I must provide
> this guarantee then I have to wait until 3.0 to introduce these changes.
> It's not a good thing for us who really want to provide the user with what
> they really need in the end as soon as possible.
>
> We must allow for rapid progression. Like I said I will be willing to make
> the guarantee once we're in a 3.0 or 4.0. But not now. Life is hard enough
> for us already. Let's keep the load light and help users when and if there
> really are API issues in the end. But it's safer to say we provide no
> guarantee than to say that we do guarantee back compat.
>
You can have rapid progression easily enough, adding all the features
you want, it simply must be additive for 2.x releases..shoot jetty has
added countless features in 6.1.[1 through 19] releases...but the api
has remained solid. We have been kicking around going to 6.2 but we
missed the spots in the past with lots of features at once and now
with 7 (and a complete packaging change and some api breaks) going
final soon it doesn't make much sense to go back and do a 6.2 as much.
anyway, say I want to incorporate ADS into a stack, you can not
reasonably expect me to make that commitment if your going to require
me to tell my users that 'oh, I updated ADS versions for this release
and all your old data needs to be reloaded. good luck!' That would be
kinda nasty.
Personally there are some uses that I couldn't care less about that
for, like continuum build histories....not a terrible thing to lose in
my opinion if it comes to it...but all your user information? that is
a different deal..
in summary, public api is important, two key ones being the api for
embedding ads and the data store underneath, keep those two solid and
probably in good shape :)
all in my opinion of course
jesse
> --
> Alex Karasulu
> My Blog :: http://www.jroller.com/akarasulu/
> Apache Directory Server :: http://directory.apache.org
> Apache MINA :: http://mina.apache.org
>
>
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Alex Karasulu <ak...@gmail.com>.
On Tue, Aug 11, 2009 at 5:17 PM, Emmanuel Lecharny <el...@apache.org>wrote:
> Alex Karasulu wrote:
>
>> I think we're on the same page. But I would add one more caveat, that Y
>> "tries" to maintain API compatibility but there is no guarantee.
>>
> Why can't we guarantee that if the API is changed, then the old API will
> still be available, but marked as @deprecated, until the next X release ? Is
> it too strong a constraint?
>
Yeah I think it is too much. Not feeling too generous on the API front
since it's going to see lots of flux. Don't want our hands tied like it was
during all these 1.0/1.5 branches. I want to move faster. The faster we
move we can come back in like 3.0 and say Y can guarantee API backwards
compatibility.
>
> There is also an aspect which is not related to the API : configuration
> _and_ data. For Minor versions, we must guarantee a compatible
> configuration, and a compatible dataBase, otherwise we -at least- must
> provide teh tooling to migrate easily both of them.
>
> Thoughts ?
>
I'm not willing to guarantee this. Technically the database format and the
configuration format/scheme is yet another interface the user is faced with
regarding ADS. When I say interface I mean it very broadly to include data
formats and things like configuration.
I might want to slowly migrate some configuration feature that was in the
XML format slowly over two feature releases into ADS. If I must provide
this guarantee then I have to wait until 3.0 to introduce these changes.
It's not a good thing for us who really want to provide the user with what
they really need in the end as soon as possible.
We must allow for rapid progression. Like I said I will be willing to make
the guarantee once we're in a 3.0 or 4.0. But not now. Life is hard enough
for us already. Let's keep the load light and help users when and if there
really are API issues in the end. But it's safer to say we provide no
guarantee than to say that we do guarantee back compat.
Let's just
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> I think we're on the same page. But I would add one more caveat, that Y
> "tries" to maintain API compatibility but there is no guarantee.
Why can't we guarantee that if the API is changed, then the old API will
still be available, but marked as @deprecated, until the next X release
? Is it too strong a constraint?
There is also an aspect which is not related to the API : configuration
_and_ data. For Minor versions, we must guarantee a compatible
configuration, and a compatible dataBase, otherwise we -at least- must
provide teh tooling to migrate easily both of them.
Thoughts ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Alex Karasulu <ak...@gmail.com>.
I think we're on the same page. But I would add one more caveat, that Y
"tries" to maintain API compatibility but there is no guarantee. Z is what
only guarantees API compatibility.
Thanks guys for the feedback. I guess we should just go with this unless
anyone has any objections until release time.
Regards,
Alex
On Tue, Aug 11, 2009 at 4:34 PM, Emmanuel Lecharny <el...@apache.org>wrote:
> Jesse McConnell wrote:
>
>> o We have major.minor.micro numbers:
>>> - major number denotes massive architectural shift
>>> - minor number denotes feature introductions
>>> - micro number denotes bug fixes and optimizations without changes to
>>> interfaces, db formats etc
>>>
>>>
>>
>> Why not just adopt the convention that people most commonly associate
>> with x.y.z?
>>
>> X - breaks API, no assurance that you can use out of the box
>> Y - features api alteration but basic assurance of api compat
>> Z - bug fixes and maintenance releases
>>
>>
> I don't think it's far from Alex proposal. As we don't have that much API
> exposed, we can say that Y also means the API is not broken. That probably
> will imply some @deprecated annotation, nothing much
>
> I don't see a need to do anything else unless your dealing with some
>> requirement being forced on you
>>
>>
> Nothing can force us ;)
>
>> fwiw your new one is far more inline with that basic idea and is much
>> better then your previous one dealing with .0 and .5 and that
>> confusion...
>>
>>
> This .5 stuff was introduced just as we wanted to move to Java 5, à la
> Tomcat (remember the 5.0/5.5 versions. Looking back in anger, it was not
> really a good idea...
>
> So basically, +1 for Alex proposal, assuming Jesse proposal fits in it.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Emmanuel Lecharny <el...@apache.org>.
Jesse McConnell wrote:
>> o We have major.minor.micro numbers:
>> - major number denotes massive architectural shift
>> - minor number denotes feature introductions
>> - micro number denotes bug fixes and optimizations without changes to interfaces, db formats etc
>>
>
> Why not just adopt the convention that people most commonly associate
> with x.y.z?
>
> X - breaks API, no assurance that you can use out of the box
> Y - features api alteration but basic assurance of api compat
> Z - bug fixes and maintenance releases
>
I don't think it's far from Alex proposal. As we don't have that much
API exposed, we can say that Y also means the API is not broken. That
probably will imply some @deprecated annotation, nothing much
> I don't see a need to do anything else unless your dealing with some
> requirement being forced on you
>
Nothing can force us ;)
> fwiw your new one is far more inline with that basic idea and is much
> better then your previous one dealing with .0 and .5 and that
> confusion...
>
This .5 stuff was introduced just as we wanted to move to Java 5, à la
Tomcat (remember the 5.0/5.5 versions. Looking back in anger, it was not
really a good idea...
So basically, +1 for Alex proposal, assuming Jesse proposal fits in it.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Jesse McConnell <je...@gmail.com>.
> o We have major.minor.micro numbers:
> - major number denotes massive architectural shift
> - minor number denotes feature introductions
> - micro number denotes bug fixes and optimizations without changes to interfaces, db formats etc
Why not just adopt the convention that people most commonly associate
with x.y.z?
X - breaks API, no assurance that you can use out of the box
Y - features api alteration but basic assurance of api compat
Z - bug fixes and maintenance releases
I don't see a need to do anything else unless your dealing with some
requirement being forced on you
fwiw your new one is far more inline with that basic idea and is much
better then your previous one dealing with .0 and .5 and that
confusion...
cheers!
jesse
--
jesse mcconnell
jesse.mcconnell@gmail.com
On Tue, Aug 11, 2009 at 08:04, Alex Karasulu<ak...@apache.org> wrote:
> Not like we've had enough conversations that sucked up vast amounts of our
> time before on this topic. However after a conversation with Emmanuel I
> think we might have to present another approach.
>
> Current Scheme
> ----------------------
>
> o We have major.minor.micro numbers.
> - major number denotes massive architectural shift
> - minor number denotes feature introductions
> - micro number denotes bug fixes and optimizations without changes to
> interfaces, db formats etc
> o Minor numbers were either 0 or 5. The 5 was for experimental branches
> with many big features being added across different releases in the branch.
> The 0 was for stable branches where no new features were being added but
> only fixes and optimizations were made.
> o The 0 or 5 schema came from the even/odd schema used in the older linux
> versioning scheme for the kernels before 2.6. We switched to 0/5 because we
> wanted the move from 1.0 to 1.5 to mean more than a number change but to
> represent the shift in JDK compatibilities. 1.5 will only run on JDK 1.5
> and up.
>
> There's some good things about this schema and some bad things.
>
> 1. The scheme used takes a long time to bring about a minor release with
> "stable" feature additions.
> 2. Many of our 1.5 releases though were more stable than our 1.0 so this
> connotation was no longer working for us.
> 3. The scheme was slowing us down but hopefully (not that we could measure
> it) was leading to a more stable LDAP server. Not like we were building a
> desktop app that can get restarted to clear out leaks and such.
> 4. The scheme is just strange. Going from 1.0 -> 1.5 then to 2.0 is odd.
> What do we do go to 2.5 next?
> 5. What about nice little features that did not take time to do but must
> wait for other major features to be deemed 'stable' and usable? They don't
> get to the user fast enough.
>
> I'm sure lots more can be found for and against this model. But at this
> point with the 0/5 stuff is just odd lookin and hard to make sense of.
> After a convo with Emm on IRC we came up with the following new scheme:
>
> Future Scheme
> --------------------
>
> o We have major.minor.micro numbers:
> - major number denotes massive architectural shift
> - minor number denotes feature introductions
> - micro number denotes bug fixes and optimizations without changes to
> interfaces, db formats etc
> o We bump up minor numbers whenever we add a new feature no matter how
> many new things were added.
> o We bump up micro numbers in case we make a bug fix or improvement.
>
> The idea here is to just keep bumping organically as we like. We can for
> example just go to 2.0.0-rc1 after 1.5.5. This seems like a natural
> progression to get us out of this old scheme with one last .5 increment.
> Then we can just keep bumping as we add feature after feature without the
> requirement for micro bug fix releases. So we can have a 2.1.0 then a 2.1.1
> etc or just jump to 2.2.0 from 2.1.0. Up to us. This is the cool thang
> about it.
>
> With this freedom comes benefits to our users. They get to see features
> faster since we do more releases back to back. Hopefully though greater bug
> introduction will not be there. But this is a balanced risk we will have to
> take. So our releases will sort of be like what Atlassian does for example
> for JIRA and Confluence.
>
> Thoughts?
>
> --
> Alex Karasulu
> My Blog :: http://www.jroller.com/akarasulu/
> Apache Directory Server :: http://directory.apache.org
> Apache MINA :: http://mina.apache.org
>
>
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Emmanuel Lecharny <el...@apache.org>.
Martin Alderson wrote:
> Hi guys,
>
> To clarify, do we go from e.g. 2.2.6 to 2.3.0, 2.3.6 or 2.3.7? It doesn't really matter but I just wanted to make sure I understand.
>
2.2.6 -> 2.2.7 if this is a bug fix
2.2.6 -> 2.3.0 if it's a minor release
> Some thoughts...
>
> Is the minor number just there to indicate to users that shiny new features have been added to ApacheDS? Does it give them a way to avoid those new features (i.e. if the user is only interested in bug fixes)?
>
yes.
> If bug fixes are only released for the latest minor version then the only way for users to get those bug fixes is to also get the latest new feature which might break backwards compatibility.
>
We can maintain older versions too, but I would say it's a matter of
having volunteers ready to do that.
> If you are going to maintain a separate branch just for bug fixes is that just for the 0 minor version i.e. 2.0.X like it is now? So people who are on 2.1.X will have to upgrade to 2.2.X etc to keep up with the big fixes?
>
Once a tag is created, branches start at this tag. Ie, if we release
2.2.0, then trunk will be for 2.3.0 and 2.2.1 will be the bug fix for
the tagged version 2.2.6. We can also maintain a 2.1.14 version, if needed.
> When you release ApacheDS 3 do you abandon ApacheDS 2 so users must upgrade to take advantage of the latest bug fixes?
>
Not necessarily. But likely, unless some people are willing to maintain
it. Httpd 1.3 is still maintained, but not heavily.
> I think it is very important for any changes that require the user to do something other than just upgrade be well labelled and avoidable without compromising the security or stability of the server. For that I think you need at least two main branches as you have now (1.0.X and 1.5.X), one for serious bug fixes and one for new backwards compatibility breaking functionality.
>
When 2.0.0 will be released, we will consider 1.0 as dead wood. That
means we won't add any feature to this branch. When 3.0.0 will be
release, 2.0.0 will be a bug fix only branch. And so on.
> The question is what to do with the other changes that don't break backwards compatibility and aren't security / stability fixes. Assuming we don't want to maintain more than 2 branches these changes need to be grouped with one of them.
>
> Apologies if that all came across a bit muddled or unfinished - gotta run!
>
> Martin
>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
RE: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Martin Alderson <Ma...@salfordsoftware.co.uk>.
Hi guys,
To clarify, do we go from e.g. 2.2.6 to 2.3.0, 2.3.6 or 2.3.7? It doesn't really matter but I just wanted to make sure I understand.
Some thoughts...
Is the minor number just there to indicate to users that shiny new features have been added to ApacheDS? Does it give them a way to avoid those new features (i.e. if the user is only interested in bug fixes)?
If bug fixes are only released for the latest minor version then the only way for users to get those bug fixes is to also get the latest new feature which might break backwards compatibility.
If you are going to maintain a separate branch just for bug fixes is that just for the 0 minor version i.e. 2.0.X like it is now? So people who are on 2.1.X will have to upgrade to 2.2.X etc to keep up with the big fixes?
When you release ApacheDS 3 do you abandon ApacheDS 2 so users must upgrade to take advantage of the latest bug fixes?
I think it is very important for any changes that require the user to do something other than just upgrade be well labelled and avoidable without compromising the security or stability of the server. For that I think you need at least two main branches as you have now (1.0.X and 1.5.X), one for serious bug fixes and one for new backwards compatibility breaking functionality.
The question is what to do with the other changes that don't break backwards compatibility and aren't security / stability fixes. Assuming we don't want to maintain more than 2 branches these changes need to be grouped with one of them.
Apologies if that all came across a bit muddled or unfinished - gotta run!
Martin
Re: [ApacheDS] How about yet another versioning scheme conversation
gang?
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
+1 for the "future scheme" as it's the same we're using for Studio. ;)
After 14 releases of Studio using the scheme, I have to say it's my
favorite...
Regards,
Pierre-Arnaud
On Tue, Aug 11, 2009 at 3:04 PM, Alex Karasulu <ak...@apache.org> wrote:
> Not like we've had enough conversations that sucked up vast amounts of our
> time before on this topic. However after a conversation with Emmanuel I
> think we might have to present another approach.
>
> Current Scheme
> ----------------------
>
> o We have major.minor.micro numbers.
> - major number denotes massive architectural shift
> - minor number denotes feature introductions
> - micro number denotes bug fixes and optimizations without changes to
> interfaces, db formats etc
> o Minor numbers were either 0 or 5. The 5 was for experimental branches
> with many big features being added across different releases in the branch.
> The 0 was for stable branches where no new features were being added but
> only fixes and optimizations were made.
> o The 0 or 5 schema came from the even/odd schema used in the older linux
> versioning scheme for the kernels before 2.6. We switched to 0/5 because we
> wanted the move from 1.0 to 1.5 to mean more than a number change but to
> represent the shift in JDK compatibilities. 1.5 will only run on JDK 1.5
> and up.
>
> There's some good things about this schema and some bad things.
>
> 1. The scheme used takes a long time to bring about a minor release with
> "stable" feature additions.
> 2. Many of our 1.5 releases though were more stable than our 1.0 so this
> connotation was no longer working for us.
> 3. The scheme was slowing us down but hopefully (not that we could measure
> it) was leading to a more stable LDAP server. Not like we were building a
> desktop app that can get restarted to clear out leaks and such.
> 4. The scheme is just strange. Going from 1.0 -> 1.5 then to 2.0 is odd.
> What do we do go to 2.5 next?
> 5. What about nice little features that did not take time to do but must
> wait for other major features to be deemed 'stable' and usable? They don't
> get to the user fast enough.
>
> I'm sure lots more can be found for and against this model. But at this
> point with the 0/5 stuff is just odd lookin and hard to make sense of.
> After a convo with Emm on IRC we came up with the following new scheme:
>
> Future Scheme
> --------------------
>
> o We have major.minor.micro numbers:
> - major number denotes massive architectural shift
> - minor number denotes feature introductions
> - micro number denotes bug fixes and optimizations without changes to
> interfaces, db formats etc
> o We bump up minor numbers whenever we add a new feature no matter how
> many new things were added.
> o We bump up micro numbers in case we make a bug fix or improvement.
>
> The idea here is to just keep bumping organically as we like. We can for
> example just go to 2.0.0-rc1 after 1.5.5. This seems like a natural
> progression to get us out of this old scheme with one last .5 increment.
> Then we can just keep bumping as we add feature after feature without the
> requirement for micro bug fix releases. So we can have a 2.1.0 then a 2.1.1
> etc or just jump to 2.2.0 from 2.1.0. Up to us. This is the cool thang
> about it.
>
> With this freedom comes benefits to our users. They get to see features
> faster since we do more releases back to back. Hopefully though greater bug
> introduction will not be there. But this is a balanced risk we will have to
> take. So our releases will sort of be like what Atlassian does for example
> for JIRA and Confluence.
>
> Thoughts?
>
> --
> Alex Karasulu
> My Blog :: http://www.jroller.com/akarasulu/
> Apache Directory Server :: http://directory.apache.org
> Apache MINA :: http://mina.apache.org
>
>