Your scenario sounds fine; but I thought the handling of major/minor/patch was
a different topic?
On Thursday, 7 April 2011 at 1:13 AM, Justin Deoliveira wrote:
In general I support the idea but I think the proposal lacks some specifics
about how version number changes relate to api changes. Currently we have the
numbering system <major>.<minor>.<patch> and our policy is:
>
> major: while I have never been around for major version change I take this to
> mean all changes are fair game.
> minor: major api
> patch: minor api changes... mostly just additions
>
When I converted the developers guide I noted that the project policy on
version numbers does not match what we do:
- http://docs.geotools.org/latest/developer/guide/conventions/version.html
> Each GeoTools module contains it’s own version number. Version numbers are
> based on 3 digits:
>
> <major>.<minor>.<patch>
> Major (first digit), is incremented to indicate that a module has lost full
> compatibility to earlier versions. So you can safely upgrade to later
> versions of a module so long as the major version has not changed.
> Minor (second digit) is incremented whenever new features are added. Modules
> are forward compatible across minor versions, but usually not backward
> compatible.
> Patch (last digit) is for bug fixes. It is used to indicate fixes in bugs
> only. No new features were made and full compatibility is preserved.
In particular we do not allow modules to each have their own version number.
>
> So the new scheme would basically mean:
>
> major: major api
> minor: minor api changes... mostly just additions
> patch: ? no api.. .just bug fixes?
>
>
>
I do like your definition; a minor release allowing additions but maintaining
full "binary" compatibility. I think that matches what we do; and allows for
formal patch releases that just contain bug fixes like you released yesterday.
> I am curious as to what a patch release implies... consider we release gt
> 8.0.0. Then let's say we fix some bugs, so we put out 8.0.1. Great. Then
> someone comes along and wants to make an api addition. Since it is non
> breaking we put it into 8.1.0. Does this mean no more 8.0.x releases? I guess
> so.
>
>
>
My understanding is from that point you could have:
8.1.1 - a patch release against 8.1.0
8.0.2 - a patch release against the earlier 8.0.0 (I assume someone would be on
the hook with a deployed app for such drastic action to be taken)
>
> Just trying to walk myself through the various scenarios.
>
>
>
np.
Jody
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
