Quantcast

release process

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
33 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

release process

Jochen Theodorou
Hi all,

since the release did get out, big thanks to Paul here, I think it would
be good if the next release could be done by someone else than Paul or
Cedric. For example me ;) That is because I would like us to have at
least 4 or 5 people being able to do a release. And then there is the
question if maybe our release process could be used as a model for git
based projects in the incubator. There was a thread about such a
skeleton not too long ago. Of course I am aware of that we have a
slightly different publication location than most of them will have, but
still. Also it would force us to create proper documentation of the
process ;)

bye Jochen

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: release process

paulk_asert
+1 with a few comments below.

There has been discussion about releases for 2.4.9, 2.5.0-beta-1 and 3.0.0-ea-1. Perhaps we should split between us? I'd suggest I do the first two with you as "co-pilot" and swap roles for the third?

Wrt promoting our release process/scripts, I'd probably hold off a bit. We're on a journey to move more pieces onto Apache infrastructure. I'd prefer to direct energies to that. If we make a few more steps in that direction, our scripts will be closer to what other projects need and there'll probably be less to document too.

Cheers, Paul.


On 20 Jan 2017 12:34 AM, "Jochen Theodorou" <[hidden email]> wrote:
Hi all,

since the release did get out, big thanks to Paul here, I think it would be good if the next release could be done by someone else than Paul or Cedric. For example me ;) That is because I would like us to have at least 4 or 5 people being able to do a release. And then there is the question if maybe our release process could be used as a model for git based projects in the incubator. There was a thread about such a skeleton not too long ago. Of course I am aware of that we have a slightly different publication location than most of them will have, but still. Also it would force us to create proper documentation of the process ;)

bye Jochen


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: release process

Jochen Theodorou


On 19.01.2017 20:07, Paul King wrote:
> +1 with a few comments below.
>
> There has been discussion about releases for 2.4.9, 2.5.0-beta-1 and
> 3.0.0-ea-1. Perhaps we should split between us? I'd suggest I do the
> first two with you as "co-pilot" and swap roles for the third?

the first two time-wise would be 2.5.0-beta-1 and 3.0.0-ea-1 in my
opinion. But yes, we can do it like that. I guess we will need to set a
time for that, once 2.5.0-beta-1 is ready to go, but first we need to
merge the parrot branch ;)

> Wrt promoting our release process/scripts, I'd probably hold off a bit.
> We're on a journey to move more pieces onto Apache infrastructure. I'd
> prefer to direct energies to that. If we make a few more steps in that
> direction, our scripts will be closer to what other projects need and
> there'll probably be less to document too.

fine with me

bye Jochen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: release process

paulk_asert
Wasn't the consensus to have parrot just in 3.0? So we could make the 2_5_X branch now?

On 20 Jan 2017 8:08 PM, "Jochen Theodorou" <[hidden email]> wrote:


On 19.01.2017 20:07, Paul King wrote:
+1 with a few comments below.

There has been discussion about releases for 2.4.9, 2.5.0-beta-1 and
3.0.0-ea-1. Perhaps we should split between us? I'd suggest I do the
first two with you as "co-pilot" and swap roles for the third?

the first two time-wise would be 2.5.0-beta-1 and 3.0.0-ea-1 in my opinion. But yes, we can do it like that. I guess we will need to set a time for that, once 2.5.0-beta-1 is ready to go, but first we need to merge the parrot branch ;)

Wrt promoting our release process/scripts, I'd probably hold off a bit.
We're on a journey to move more pieces onto Apache infrastructure. I'd
prefer to direct energies to that. If we make a few more steps in that
direction, our scripts will be closer to what other projects need and
there'll probably be less to document too.

fine with me

bye Jochen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: release process

Jochen Theodorou
On 20.01.2017 13:14, Paul King wrote:
> Wasn't the consensus to have parrot just in 3.0? So we could make the
> 2_5_X branch now?

may have missed something like a consensus I guess. But frankly I don´t
get why parrot should not even be optional in 2.5.x.

bye Jochen

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: release process

paulk_asert
The concern was added complexity but maybe it isn't much different to normal. From my side, I need to play around some more to confirm either way.

At a minimum, we'd need to use java 8 to do the 2.5.x releases, and have something sensible built, i.e. without the parrot option, for those compiling the src from 7 or running on 7. So probably some build changes and plugin capability.

Cheers Paul.

On 21 Jan 2017 5:01 AM, "Jochen Theodorou" <[hidden email]> wrote:
On 20.01.2017 13:14, Paul King wrote:
Wasn't the consensus to have parrot just in 3.0? So we could make the
2_5_X branch now?

may have missed something like a consensus I guess. But frankly I don´t get why parrot should not even be optional in 2.5.x.

bye Jochen

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: release process

Cédric Champeau
Let me rephrase what I said. My concern is not about complexity. My concern is that parrot is an experimental parser, that requires Java 8, and an additional dependency, antlr4, which conflicts with an existing dependency, antlr2. I don't want to mix things like that. The new parser should be, as all Java 8+ things, Groovy 3 only. There's little, if any, value in mixing this in 2.5, but there's a high risk for users. Risks of unwanted behavior, bigger distribution, additional flags, ...

I thought I was clear but it seems not: 
  - 2.5 should be Java 7 and macros.
  - 3.0 should be the blow everything up version, that bumps to Java 8, adds the new parser, and removes the old call site caching stuff

It will be easier for us too, because it's pretty clear where we can merge experimental stuff, as well as releasing betas, alphas, whatever you want to call them. But let's not mix stable and unstable things in a single distribution. Git branches are not so hard.

2017-01-20 21:52 GMT+01:00 Paul King <[hidden email]>:
The concern was added complexity but maybe it isn't much different to normal. From my side, I need to play around some more to confirm either way.

At a minimum, we'd need to use java 8 to do the 2.5.x releases, and have something sensible built, i.e. without the parrot option, for those compiling the src from 7 or running on 7. So probably some build changes and plugin capability.

Cheers Paul.

On 21 Jan 2017 5:01 AM, "Jochen Theodorou" <[hidden email]> wrote:
On 20.01.2017 13:14, Paul King wrote:
Wasn't the consensus to have parrot just in 3.0? So we could make the
2_5_X branch now?

may have missed something like a consensus I guess. But frankly I don´t get why parrot should not even be optional in 2.5.x.

bye Jochen


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: release process

Jochen Theodorou
On 20.01.2017 22:04, Cédric Champeau wrote:
> Let me rephrase what I said. My concern is not about complexity. My
> concern is that parrot is an experimental parser, that requires Java 8,
> and an additional dependency, antlr4, which conflicts with an existing
> dependency, antlr2.

antlr2 and antrl4 are not conflicting. They use different package spaces
and have no compile/runtime dependencies

> I don't want to mix things like that. The new parser
> should be, as all Java 8+ things, Groovy 3 only.

I see no problem in distributing java8 code in 2.5 in an optional part

> There's little, if any,
> value in mixing this in 2.5, but there's a high risk for users. Risks of
> unwanted behavior, bigger distribution, additional flags, ...

for me the value is that users can try it out in 2.5. Who knows how long
it will take to get 3.0 out. There might be a 2.6 before even. Yes,
there will be a maybe 1MB bigger distribution (antlr4 jar is 604K) and
there will be 1 additional flags. It being optional means the groovy
jars can stay the same size though.

> I thought I was clear but it seems not:
>    - 2.5 should be Java 7 and macros.
>    - 3.0 should be the blow everything up version, that bumps to Java 8,
> adds the new parser, and removes the old call site caching stuff

Oh clear it is, I just disagree.

> It will be easier for us too, because it's pretty clear where we can
> merge experimental stuff, as well as releasing betas, alphas, whatever
> you want to call them. But let's not mix stable and unstable things in a
> single distribution. Git branches are not so hard.

Git branches not, no. But I see use for the parser now, not in who knows
when. I assume it will be at least a year before there is a 3.0.0 rc.

bye Jochen

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: release process

Cédric Champeau
We can release 2.5.0-beta-1 and 3.0.0-alpha-1 concurrently. I see no problem with that. And it would be cleaner. If we release, say, 2.5 final with parrot as an optional module, nothing prevents people from using it real projects. I don't think we want to pay the price of maintaining parrot for 2.5.

Le 20 janv. 2017 22:58, "Jochen Theodorou" <[hidden email]> a écrit :
On 20.01.2017 22:04, Cédric Champeau wrote:
Let me rephrase what I said. My concern is not about complexity. My
concern is that parrot is an experimental parser, that requires Java 8,
and an additional dependency, antlr4, which conflicts with an existing
dependency, antlr2.

antlr2 and antrl4 are not conflicting. They use different package spaces and have no compile/runtime dependencies

I don't want to mix things like that. The new parser
should be, as all Java 8+ things, Groovy 3 only.

I see no problem in distributing java8 code in 2.5 in an optional part

There's little, if any,
value in mixing this in 2.5, but there's a high risk for users. Risks of
unwanted behavior, bigger distribution, additional flags, ...

for me the value is that users can try it out in 2.5. Who knows how long it will take to get 3.0 out. There might be a 2.6 before even. Yes, there will be a maybe 1MB bigger distribution (antlr4 jar is 604K) and there will be 1 additional flags. It being optional means the groovy jars can stay the same size though.

I thought I was clear but it seems not:
   - 2.5 should be Java 7 and macros.
   - 3.0 should be the blow everything up version, that bumps to Java 8,
adds the new parser, and removes the old call site caching stuff

Oh clear it is, I just disagree.

It will be easier for us too, because it's pretty clear where we can
merge experimental stuff, as well as releasing betas, alphas, whatever
you want to call them. But let's not mix stable and unstable things in a
single distribution. Git branches are not so hard.

Git branches not, no. But I see use for the parser now, not in who knows when. I assume it will be at least a year before there is a 3.0.0 rc.

bye Jochen

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: release process

Graeme Rocher-2
In reply to this post by Cédric Champeau
Is the plan for 3.0 to break binary compatibility for existing libraries?

Personally I don't think we should ever have a version that we call
"blow everything up version" that would be a big red flag for me.
Imagine Oracle announcing the Java JDK "blow everything up" edition.

Is there a way to retain some form of binary compatibility maybe
through `groovy-compat` that contains the old call site caching?

If 3.0 is to be a breaking binary incompatible release then I see real
value in adding parrot to a version of Groovy that is binary
compatible since it will be a VERY long time before folks are able to
even consider 3.0 so personally I am with Jochen on this one.

Regards,


On Fri, Jan 20, 2017 at 10:04 PM, Cédric Champeau
<[hidden email]> wrote:

> Let me rephrase what I said. My concern is not about complexity. My concern
> is that parrot is an experimental parser, that requires Java 8, and an
> additional dependency, antlr4, which conflicts with an existing dependency,
> antlr2. I don't want to mix things like that. The new parser should be, as
> all Java 8+ things, Groovy 3 only. There's little, if any, value in mixing
> this in 2.5, but there's a high risk for users. Risks of unwanted behavior,
> bigger distribution, additional flags, ...
>
> I thought I was clear but it seems not:
>   - 2.5 should be Java 7 and macros.
>   - 3.0 should be the blow everything up version, that bumps to Java 8, adds
> the new parser, and removes the old call site caching stuff
>
> It will be easier for us too, because it's pretty clear where we can merge
> experimental stuff, as well as releasing betas, alphas, whatever you want to
> call them. But let's not mix stable and unstable things in a single
> distribution. Git branches are not so hard.
>
> 2017-01-20 21:52 GMT+01:00 Paul King <[hidden email]>:
>>
>> The concern was added complexity but maybe it isn't much different to
>> normal. From my side, I need to play around some more to confirm either way.
>>
>> At a minimum, we'd need to use java 8 to do the 2.5.x releases, and have
>> something sensible built, i.e. without the parrot option, for those
>> compiling the src from 7 or running on 7. So probably some build changes and
>> plugin capability.
>>
>> Cheers Paul.
>>
>> On 21 Jan 2017 5:01 AM, "Jochen Theodorou" <[hidden email]> wrote:
>>>
>>> On 20.01.2017 13:14, Paul King wrote:
>>>>
>>>> Wasn't the consensus to have parrot just in 3.0? So we could make the
>>>> 2_5_X branch now?
>>>
>>>
>>> may have missed something like a consensus I guess. But frankly I don´t
>>> get why parrot should not even be optional in 2.5.x.
>>>
>>> bye Jochen
>>>
>



--
Graeme Rocher
1234
Loading...