On Wed, Apr 6, 2011 at 9:33 AM, Jody Garnett <[email protected]> wrote:
> Your scenario sounds fine; but I thought the handling of
> major/minor/patch was a different topic?
>
> To me it seems to make sense to consider them in the same proposal
conversation. Since one directly impacts the other does it not?
> 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)
>
Ok. i am just worried about maintaining multiple stable release streams. But
if I understand you correctly we would not be doing that unless someone has
to put out a release against an early version. And in that case the onus
would be on them to do so.
How do we organize the release download pages and sourceforge? Currently we
have 2.7.x, 2.6.x releases, etc... Does that change to 8.0.x and 8.1.x.
etc...? Or just an 8.x stream?
>
>
> Just trying to walk myself through the various scenarios.
>
> np.
>
> Jody
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
