I'm not sure if this has been stated as I have not had a chance to read this thread in the last couple days, but here's my 2 cents:
I would stick with 2.6 as it has already been setup for builds, discussed in conferences and can be seen on the groovy-lang downloads page w/ release notes. I find that 2.6 follows semantic versioning just fine and should there be any need, 2.7 could be created (but probably won't).
If you main thrust is 3.0, then try to push 2.6 out as soon after 2.5 is GA as can be achieved. I find value in 2.6 as it gives a chance to step into Parrot but not JDK8 or breaking changes.
> But seriously, a project release in 2018 that supports Java 7 is extraordinary. The future is JDK 11, not 7 :)
I definitely agree, what's the rationale of supporting Java 7? The new Java release train is putting a lot of pressure on the fast adoption of latest Java versions. IMO it would be much better to focus on Java 9 compatibility.
On Tue, May 22, 2018 at 9:41 AM, Cédric Champeau <email@example.com> wrote:
2.99 or alike doesn't make sense. What if you have to release a bug fix release. 2.99.1? That's nasty :)I'm very much in favor of dropping 2.6 altogether because it's confusing as possible. We don't have 2.5 yet, and we already have alphas for 3.0. This mean we would live with 3 "live" branches for a while (2.5.x, 2.6.x and 3.x), which is too much overhead for my brain, and probably too much hassle for the maintainers of Groovy. I reckon that people wanted to have the ability to try the new parser on JDK 7. But seriously, a project release in 2018 that supports Java 7 is extraordinary. The future is JDK 11, not 7 :)
Le mar. 22 mai 2018 ŕ 09:33, mg <firstname.lastname@example.org> a écrit :
This is one reason why - under the given constraints - Russel's 2.99.x or my 2.97.x would be better choices than 2.9.x(once you get beyond "this is not how things are done").
Also consider what happens if, for some reason, the current 2.5.x branch was to continue beyond 2.5.x (without switching to 2.6.x === 3.0-- , i.e. without breaking changes).Then you would have to skip 2.6.x , and go directly to 2.7.x, which would be much more confusing...
The key sentence here is "under the given constraints". In a perfect, clean-room-world we would not be having this discussion...
If you go with 2.9 now, and for unforseeable reasons the 2.x branch
continues, you will have 2.6, 2.7, 2.8 and then the prematurely added
What would you think about any other project versioning like that?
Even with a given explanation, it looks weird and chaotic.
On Tue, May 22, 2018 at 11:12 AM, Paul King <email@example.com> wrote:
> 2.6/3.0-- has only undergone alpha releases. The fact that 2.7/2.8 are
> missing and that people stop to think is a good thing.
> We are planning breaking changes for 3 (and hence 2.6/3.0--). With semantic
> versioning, 2.6/3.0-- should not have such changes.
> So it really should be versions 3 and 4 but since we are going to drop
> support for 2.6/3.0-- straight away, it hardly seems worthy
> of a dedicated whole version. I think 2.9 is a good compromise version
> Dropping it altogether is another option but if you remember it was
> non-committer contributors that wanted this change and did
> most of the (original at least) contributions. We've done all the work, I
> say let's just release as 2.9 and then drop it. If outside
> contributors want to continue bug fixes on it, so be it.
> Cheers, Paul.
> On Tue, May 22, 2018 at 1:12 AM, John Wagenleitner
> <firstname.lastname@example.org> wrote:
>> My opinion is that it should be left as 2.6. Since 2.6 has already
>> undergone several pre-releases I think it will may be more confusing to
>> re-number now. Renumbering may also give the impression that a 2.7 or 2.8
>> might be coming or at least make some wonder what happened to those
>> On Sat, May 19, 2018 at 8:58 PM Paul King <email@example.com> wrote:
>>> I was wondering what people thought about renumbering Groovy 2.6 to 2.9.
>>> It is only a subtle change but I think better conveys that it isn't a
>>> small step up
>>> from 2.5 but rather something just a bit short of 3.
>>> Cheers, Paul.