Branching & Release strategy

[Stephen Sadowski]

All,

Since we're rolling up to the 10/1 feature freeze, I wanted to start the discussion about what kind of strategy we'll use for doing the December release. 

I propose that on 10/1 we create a branch for the release that will contain only fixes, not features, allowing master to continue to be the mainline, then when the time comes, we tag and release off the branch. I admit this is a pretty old school way of doing it, but it is also a clear and simple method that provides easy visibility for newcomers.

I don't actually care if we do this, but I do want to respect the feature freeze process without impacting other PRs and improvements, so if someone knows a better method, I'm very open to it!

Thanks,

-S

[Adam Hopkins]

Stephen:

So I understand the proposal ...

Development continues to happen on master. PRs continue merging to master. There is a new branch (call it v18.12-LTS). Whenever the CODE freeze happens, we merge master into the release branch. When that is ready, we build and push to PyPI from the release branch.

Then, for some period of time (3 months for regular releases and XXX months for LTS), that branch remains active with any bug fixes or hotfixes coming from where? For a regular release they could just come from master. But, it seems like LTS will need its own branches after release.

Do I have this right?

--

Adam Hopkins

ad...@amhopkins.com 

Sep 25, 2018, 10:32 PM by stephen....@gmail.com:

--

You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.

To post to this group, send email to sani...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/d4166bc4-dfca-434b-b791-b17a52394f57%40googlegroups.com.

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

[Stephen Sadowski]

Sorry, to a point we've been using the term code freeze somewhat interchangeably.

With a 2 month cycle prior to release, we're actually doing a feature freeze when we branch. IE, we still want to fix broken things, but we don't want to make any changes to existing feature functionality or add new features. Especially key in an LTS, I think.

It adds some complexity to managing the code base, but the difference is that while an LTS continues to be supported with security and (hopefully very) minor bug fixes throughout the LTS support period, master takes all new things, be they fixes or features or changes. for the other 3 quarterly releases in a span, this essentially means that something that is not an LTS can simply be tagged from master.

Hopefully this makes sense, because with an LTS we're effectively maintaining the code at what we consider a supportable, stable point and we will want to make sure that we can easily apply fixes to it. If we continuously operate in master, trying to support the LTS is a harrying notion.

So to summarize my rambling: LTS releases get their own branches, normal quarterlies are tagged from master. Feature freeze happens at branching for the LTS, code freeze happens sometime slightly before the release (where we only accept emergency fixes, such as security issues), once the release is tagged and pushed to pypi, the LTS branch is code thawed and can accept new fixes as necessary. I can diagram this in the morning, if needs be.

It keeps the LTS stable and keeps us from worrying about the master branch.

-S

On Tuesday, September 25, 2018 at 6:28:55 PM UTC-5, Adam Hopkins wrote:

Stephen:

So I understand the proposal ...

Development continues to happen on master. PRs continue merging to master. There is a new branch (call it v18.12-LTS). Whenever the CODE freeze happens, we merge master into the release branch. When that is ready, we build and push to PyPI from the release branch.

Then, for some period of time (3 months for regular releases and XXX months for LTS), that branch remains active with any bug fixes or hotfixes coming from where? For a regular release they could just come from master. But, it seems like LTS will need its own branches after release.

Do I have this right?

--

Adam Hopkins

ad...@amhopkins.com 

Sep 25, 2018, 10:32 PM by stephen....@gmail.com:

All,

Since we're rolling up to the 10/1 feature freeze, I wanted to start the discussion about what kind of strategy we'll use for doing the December release. 

I propose that on 10/1 we create a branch for the release that will contain only fixes, not features, allowing master to continue to be the mainline, then when the time comes, we tag and release off the branch. I admit this is a pretty old school way of doing it, but it is also a clear and simple method that provides easy visibility for newcomers.

I don't actually care if we do this, but I do want to respect the feature freeze process without impacting other PRs and improvements, so if someone knows a better method, I'm very open to it!

Thanks,

-S

--

You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.