groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andres Almiray <aalmi...@gmail.com>
Subject Re: next releases
Date Tue, 17 Jan 2017 09:48:56 GMT
Hello all,

Given the explanations made by Jochen and Cédric, we may be looking at the
following:

 - 2.4.9: possible the latest release of the 2.4.x branch. Semantic
versioning dictates there should be only fixes.
 - 2.5.x: new features and fixes. Requires old parser. No breaking changes
 - 3.0-ea: new parser. remove outdated dependencies. remove deprecations
perhaps?

I'd suggest to release 2.5.0-beta and 3.0-ea together. Just like the JDK
team has been posting JDK9 EA releases, we could do the same. We know for a
fact we're going to break things, so let's make sure the public has ample
time to test out the changes.

2.5.x (and possibly 2.6.x) remain the stable version until 3.0 comes out.
Any fixes made in this branch may be backported to 2.4.9 (another reason to
hold of this release for a few weeks until 2.5.0 comes out unless we need
to patch a security hole for example).

In other words 2.4.x is slow (release time), 2.5.x is stable, 3.x is fast
(and furious? ;-)

Cheers,
Andres

-------------------------------------------
Java Champion; Groovy Enthusiast
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

On Tue, Jan 17, 2017 at 10:24 AM, Cédric Champeau <cedric.champeau@gmail.com
> wrote:

> It's not a simple decision. A beta isn't something to play with. There are
> users, and companies, using Groovy. You cannot simply say "this is new,
> let's try this". There are backwards compatibility concerns, as well as
> deployment issues. We agreed, a few months ago, to make 3.0 the breaking
> release, not 2.5. I'm not against having a 2.5 beta *and* a 3.0 beta. But
> those should be different artifacts. There's no need to mix the risks.
> Especially, there's no need to put in the same release the macro stuff and
> the requirement to upgrade to Java 8. As much as I love the idea of a
> breaking 3.0, I definitely don't like the idea of a 2.5 "beta" which is a
> "3.0 alpha". Let's make 3.0 the real breaking release, not 2.5.
>
> 2017-01-17 10:20 GMT+01:00 Jochen Theodorou <blackdrag@gmx.org>:
>
>>
>>
>> On 17.01.2017 10:17, Russel Winder wrote:
>> [...]
>>
>>> The 2.5 build still creates jars and indy jars. Isn't it about time we
>>> settle this so there are only one set of jars in a build?
>>>
>>
>> right, we should also change to indy by default for the betas
>>
>> bye jochen
>>
>
>

Mime
View raw message