[RFC] Bolt Release Process

GwendolenLynch commented 9 years ago

Background

Bolt is an evolving project and has come a long way since this commit:

commit 656959d875e1ad4e93ee528a33a10f61635ade6d
Author: bobdenotter <bobdenotter@gmail.com>
Date:   Thu Jun 14 09:07:55 2012 -0700

    Initial commit

As I write this, we have 139 contributors and over 9,000 commits… both of those number increasing steadily.

Since branching Bolt v1 and commencing on the path to Bolt v2 we've spent time thinking about how, as a community based project, to best manage our release process. Some of the points that we're trying to consider in this discussion are:

Keep the project moving… don't stagnate
Keep our processes in line with our vision of simplicity
Keep the management of processes from interfering with the fun we have writing the code, documentation, and community interaction
Learn from the success of other projects, as well as from their mistakes
Release early, release often!
New Features

For a new feature there is a three step process:

Note: This obviously doesn't include bug fixes

Step 1 RFC submission

Create a GitHub issue with the prefix of [RFC] in the subject line.

Describe:

What the feature is
What the impacts are
Step 2 RFC moved to Roadmap

Once approved, a core team member will add the feature and contributor's GitHub handle to the Roadmap wiki page

Step 3 Feature implemented and merged into version `-next`

Once the feature window is open the contributor can submit a PR for review and merging.

Schedule & Roadmap

It is proposed that the schedules follow the basic pattern of:

14 day feature window (hard limit)
14 day bug fix window (soft end-limit)
14 day contingency window (only if required)
Release!

An example would be:

Window	Open (09:00 UTC)	Close (midnight UTC)
Feature	09 March 2014	22 March 2014
Bug Fix	23 March 2014	05 April 2014
Release	06 April 2014	n/a

I have drafted a Roadmap wiki page that, if we accept this proposal, should be maintained for the 2.x development cycle and added to for each upcoming/new release.

bobdenotter commented 9 years ago

Looks good to me! :-)

CarsonF commented 9 years ago

Yeah I like it.

Symfony also has a template for their PRs (I adopted it below)

Q	A
Bug fix?	[yes	no]
New feature?	[yes	no]
BC breaks?	[yes	no]
Deprecations?	[yes	no]
Fixed tickets	[comma separated list of tickets fixed by the PR]
Changelog	[High level change for changelog]

rossriley commented 9 years ago

plus...

Q	A
Added any statics?	[yes	no]

GwendolenLynch commented 9 years ago

@rossriley I think you meant:

Q	A
Added any statics?	[CarsonF	no]

CarsonF commented 9 years ago

I never thought I would be the statics guy. I'm usually playing the opposite role with a coworker.

GwendolenLynch commented 9 years ago

"It was just one time!"

CarsonF commented 9 years ago

Seriously though, I think I've done literally like 2 methods and suggested 1.

bobdenotter commented 9 years ago

448e29cf55d7a9403cca98da77e54654

GwendolenLynch commented 9 years ago

Seriously though, I think I've done literally like 2 methods and suggested 1.

And you removed all ones in Bolt\Controllers\Frontend… versus the guy who did Bolt\Library…

bobdenotter commented 9 years ago

versus the guy who did Bolt\Library

There was literally decade-old code in there. ;-)

GwendolenLynch commented 9 years ago

Oh yes, not pointing fingers at lib.php just the Australian character :koala: that did Bolt\Library :eyes:

CarsonF commented 9 years ago

Really the only static I want is #2464

GwendolenLynch commented 9 years ago

Symfony also has a template for their PRs (I adopted it below)

Probably a separate discussion, at a later time I would guess… Unless anyone has some strong preference for this? As things stand I would see it not fit with these:

Keep our processes in line with our vision of simplicity
Keep the management of processes from interfering with the fun we have writing the code, documentation, and community interaction

That being said, this morning's IRC discussion about the 2.1 beta looks like we might be heading for a March 9 release, so if anyone has criticism/feedback on this can you get it in a.s.a.p. as the consensus seems to be in favour of this RFC's approach.

rossriley commented 9 years ago

Only addition to this, is how we keep an eye on test coverage. It's fine for contributors to submit code without test coverage but in the review somebody, either the contributor or a reviewer, or a friendly helper should do a before/after check on the code coverage.

It's only necessary for the specific module, so if the contribution was for the configuration classes, just run phpunit tests/Configuration before and after the PR and make a note in the table. If there's an impact then it gives us an attempt to address it, either as part of the PR or via a separate issue/

CarsonF commented 9 years ago

Is there a tool that can do this for us?

GwendolenLynch commented 9 years ago

Yes, almost finished writing it.

GwendolenLynch commented 9 years ago

OK, looks like we're go!

bolt / bolt