> 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. p On Tue, May 22, 2018 at 9:41 AM, Cédric Champeau <cedric.champ...@gmail.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 <mg...@arscreat.com> a écrit : > >> Good point. >> >> 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... >> >> >> -------- Ursprüngliche Nachricht -------- >> Von: Thibault Kruse <tibokr...@googlemail.com> >> Datum: 22.05.18 06:31 (GMT+01:00) >> An: dev@groovy.apache.org, pa...@asert.com.au >> Betreff: Re: [DISCUSS] Renumber Groovy 2.6 to 2.9 >> >> 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 >> 2.9. >> 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 <pa...@asert.com.au> 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 >> > number. >> > >> > 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 >> > <john.wagenleit...@gmail.com> 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 >> >> versions. >> >> >> >> On Sat, May 19, 2018 at 8:58 PM Paul King <pa...@asert.com.au> wrote: >> >>> >> >>> >> >>> Hi, >> >>> >> >>> 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. >> >>> >> >>> Thoughts? >> >>> >> >>> Cheers, Paul. >> >>> >> > >> >