Non-breaking changes and puppet 3.7.x

[Kylo Ginsberg]

So Charlie, Spencer, Eric0 and I just had a quick convo on #puppet-dev about where non-breaking changes to puppet should land, given that the transition to puppet 4 will take a while for many sites. The tldr was the proposal that:

* non-breaking changes should default to 3.7.x until some time passes after 4.0 is out

For PRs, this implies a bit of a change to our SOP (which makes sense since that SOP was pretty driven by the last 2.5 years of 3.y releases). I.e. the SOP has been, roughly: only regressions in the last Y go to stable, new bug fixes and features go to master.

So I think to implement this we would instead want to:

* target non-breaking changes at stable for now (and merge up to master of course)

* when we release puppet 4, we create a 3.7.x branch and then:

** non-breaking changes go to 3.7.x (and are merged up -> stable -> master)

And then some time after 4.0 is out, we would switch that default (and the 3.7.x branch then presumably becomes security/critical fixes only).

Thoughts?

Kylo

--

Kylo Ginsberg | ky...@puppetlabs.com | irc: kylo | twitter: @kylog

Join us at PuppetConf 2015, October 5-9 in Portland, OR - http://2015.puppetconf.com.  

Register early to save 40%!

[Joshua Hoblitt]

On 12/04/2014 02:24 PM, Kylo Ginsberg wrote:
> ** non-breaking changes go to 3.7.x (and are merged up -> stable -> master)

I suspect random bug fixes will be largely submitted as PRs against the
'stable' ref. That might mean a situation of having to back merge to
3.7.x and forward merge to master. I don't see that as a major issue
but it might be a little easier on the folks wrangling PRs if 'stable'
was pointed at the 3.7.x series. With the logic being that forward
porting will be easier than back porting. Another idea would be to
remove the stable ref completely and use branch names of 3.7.x and 4.0.x.

-Josh

--

[Henrik Lindberg]

On 2014-04-12 22:24, Kylo Ginsberg wrote:
> * non-breaking changes should default to 3.7.x until some time passes
> after 4.0 is out

Eh, no, not in general please. We have lots of code removal and anything
that needs to go through the process of being
implemented both an old and a new way should not be done at all on
stable IMO except if there is burning need / bug.

We have removed lots of code to save us work, remove complexity etc.

I am fine with "non-breaking /bug fixes/ should default to 3.7.x until
some time passes after 4.0 is out".

There is no need to rename branches.

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[Kylo Ginsberg]

On Thu, Dec 4, 2014 at 3:46 PM, Henrik Lindberg <henrik....@cloudsmith.com> wrote:

On 2014-04-12 22:24, Kylo Ginsberg wrote:

* non-breaking changes should default to 3.7.x until some time passes after 4.0 is out

Eh, no, not in general please. We have lots of code removal and anything that needs to go through the process of being
implemented both an old and a new way should not be done at all on stable IMO except if there is burning need / bug.

We have removed lots of code to save us work, remove complexity etc.

I am fine with "non-breaking /bug fixes/ should default to 3.7.x until some time passes after 4.0 is out".

Ah yes, I agree. I was thinking "bug fixes" specifically (but the wrong words came out).

Maybe the criteria are more like "non-breaking bug fixes, not in support of any deprecated features, and trivially merged up to 4.x" or some such.

 

There is no need to rename branches.

I *think* we'd still need an additional branch if we want to support any level of changes to 3.7.x after 4.0 is released b/c we'd have:

* branch for 3.7.x

* branch for 4.0.x

* branch for 4.1/5.0

which could be named 3.7.x/stable/master respectively (although we should discuss Josh H's comment too). Or am I missing your point here?

Actually my biggest concern with three branches is keeping the CI pipeline alive (since it needs care and re-kicks for various reasons). Perhaps at some point post-4.0, the 3.7.x branch could have some community stewards? We did something like this for 2.7.x.

Kylo

 

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/m5qrof%24dsg%241%40ger.gmane.org.

For more options, visit https://groups.google.com/d/optout.

[DEGREMONT Aurelien]

Le 04/12/2014 22:24, Kylo Ginsberg a écrit :

So Charlie, Spencer, Eric0 and I just had a quick convo on #puppet-dev about where non-breaking changes to puppet should land, given that the transition to puppet 4 will take a while for many sites. The tldr was the proposal that:

* non-breaking changes should default to 3.7.x until some time passes after 4.0 is out

For PRs, this implies a bit of a change to our SOP (which makes sense since that SOP was pretty driven by the last 2.5 years of 3.y releases). I.e. the SOP has been, roughly: only regressions in the last Y go to stable, new bug fixes and features go to master.

Why not creating a 3.8 release which will be 3.7 + non-breaking changes from 4.0 ?
This will be more compliant with your SOP and more understandable for users.
Instead of having a 3.7.8, 3.7.9 which will introduce new features, etc...



Aurélien

[Henrik Lindberg]

On 2014-05-12 3:56, Kylo Ginsberg wrote:
> On Thu, Dec 4, 2014 at 3:46 PM, Henrik Lindberg
> <henrik....@cloudsmith.com

> <mailto:henrik....@cloudsmith.com>> wrote:
>
> On 2014-04-12 22:24, Kylo Ginsberg wrote:
>
> * non-breaking changes should default to 3.7.x until some time
> passes after 4.0 is out
>
> Eh, no, not in general please. We have lots of code removal and
> anything that needs to go through the process of being
> implemented both an old and a new way should not be done at all on
> stable IMO except if there is burning need / bug.
>
> We have removed lots of code to save us work, remove complexity etc.
>
> I am fine with "non-breaking /bug fixes/ should default to 3.7.x
> until some time passes after 4.0 is out".
>
>
> Ah yes, I agree. I was thinking "bug fixes" specifically (but the
> wrong words came out).
>
> Maybe the criteria are more like "non-breaking bug fixes, not in
> support of any deprecated features, and trivially merged up to 4.x" or
> some such.
>
>
> There is no need to rename branches.
>
>
> I *think* we'd still need an additional branch if we want to support
> any level of changes to 3.7.x after 4.0 is released b/c we'd have:
> * branch for 3.7.x
> * branch for 4.0.x
> * branch for 4.1/5.0
> which could be named 3.7.x/stable/master respectively (although we
> should discuss Josh H's comment too). Or am I missing your point here?
>

You are right when we reach 4.0.0, we will use stable for 4.0.x, and
master for 4.x, so we do need a 3.7.x branch. The workflow will be
"backwards compatible bugfixes that do not involve removed features" go
to 3.7.x, then stable, and then master.

And as you said, the work is really setting up CI and have the extra
3.7.x branch being managed.


- henrik

[Kylo Ginsberg]

I'm hoping this was answered elsewhere in the thread, but: 3.7.x would be for *bug fixes*, not for new features. New features would be introduced in master as today.

Apologies for the confusion in my initial wording.

Kylo

Aurélien

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5481699A.60104%40cea.fr.

For more options, visit https://groups.google.com/d/optout.