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?
>
>
>
>
Yeah you are totally right; it is a good time to handle it and the existing
docs are messed up, and the motivation of this was to clear up confusion.
Now I have to think ... thanks justin.
> >
> > 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.
>
>
>
Yeah for sure; there would not be a 8.0.x, 8.1.x, 8.2.x branches. If you needed
to backtrack and putout an 8.0.2 you would have to grab the 8.0.1 and make a
copy and work from there.
> 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?
>
>
>
We will just smoothly go over to 2.6.x, 2.7.x, 8.x, 9.x etc... from this
standpoint we are simply dropping the "2".
It is all good,
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
