rbaynes commented 7 years ago

RFC: formal process for developer workflow

Summary

This RFC describes a formal process for software developers who contribute to OpenAg projects. It provides a more stable software product for our users and prevents them from being bitten by untested code issues.

Motivation

Encourage good software development practices to produce a quality product.

Details

The master branch is the latest release. No active development happens on it.
The develop branch starts as a branch from master and is permanent. This is where active development happens.
Any fixes or features happen on a temporary branch off of develop. They are PR’d back to develop.
We drive develop to a stable, tested, working release then tag it with vX.Y.Z.
- When a release tag is made, the develop branch is merged back to master (which will have the same tag applied).
- We advertise to the community the new release is ready and provide release notes with a list of fixes/features.
CI (continuous integration) is always running on master and develop.
- I suggest we also figure out how to make the Travis CI system email an “ broke the build with commit ” message to a dev list.

Drawbacks

A bit more process that has been done before.

Alternatives

Continue with the current master > work branch > PR back to master process.

Deadline for comments

Deadline for comments on this RFC is Monday 2017-06-12.

rwdavis513 commented 7 years ago

Looks great to me!

gordonbrander commented 7 years ago

A disadvantage to this approach is that it requires a Sheriff to manage merges back to master. The team is rather small. I agree it can improve release reliability for large teams though. The Train model is another successful approach. Tradeoffs.

Another step toward a consistent stable release process would be to lean more heavily on CI, increase test code coverage, and reject any PRs that fail CI.

These thoughts are all offered without a strong opinion about which model is best.

BTW let's make sure to update the wiki page on Dev process if this changes.

rwdavis513 commented 7 years ago

Agreed. It does need someone to ensure things move from develop to master, but that will also help to ensure a conscious / intentional roll out of each stable release.

Definitely agree that higher test coverage and CI are important either way.

I'd say let's go ahead and approve this RFC and update the wiki as requested.

sp4ghet commented 7 years ago

@rbaynes I agree with this except for one part:

release_YYYY-MM-DD_vX.Y.Z. It's a release, and the date is stored in both the commit AND github. Let's just call it "vX.Y.Z"

Also it's been like a month since posting this and we've adopted the practice so I think it's ok to just close this and put it into https://github.com/OpenAgInitiative/rfcs

rbaynes commented 7 years ago

@Spaghet Done. Changed version and moved to rfcs.

OpenAgricultureFoundation / openag_brain