Decide on an actual release strategy

[belak]

Prezto has traditionally been a framework where you run from master directly and have your own patches added on top, but I think it may be time to add a stable branch and start tagging releases. This way we can start releasing potentially backwards incompatible changes and have a clear way to migrate between releases.

This also relates to #1329

I'm imagining a system like this:

• Any PRs will be merged into master. This will be the default branch.
• A stable branch will be added where releases will be tagged and merged to.
• Release versions should use signed tags and merges into stable should (potentially) be signed
• Versioning should probably follow semver, though I'm not sure how we should handle breaking changes of modules themselves because I don't want the version number to skyrocket.

Optional things:

• The updater would be amended to handle updating from releases (or running from the stable branch), somehow

Does anyone else have opinions or ideas on this?

[rugk]

BTW you can also easily sign the source code archives created by GitHub independently to the git tag/commits: https://github.com/rugk/gittools/blob/master/signrelease.sh

[johnpneumann]

While I think this is a good idea, I'm hesitant about it as well. While it allows more control, it also adds complexity to both the collaborators and the git log graph. While it's not a huge deal for us, the log graph does take a large hit by moving to this method. If you look at the log graph, by and large, it stays pretty much on one lane from 2011 up until all of us were added. Some things before that appear to be in the style that was popularized by nvie back in the day. Now I've said log graph a lot of times, but here's why I'm calling it out specifically:

My preferred merge method is to rebase or cherry-pick since this kind of project tends to create a hell of a log graph. It requires advanced Git knowledge compared to pressing a green button on GitHub. link

I agree that having tags and releases would be beneficial especially if it continues to garner interest (and judging by what I can see, it has continued to do so) and that having a stable and development branch would be the way to get there. I just don't want to explicitly go against what has already been brought up. I would have benefited from a stable branch when I finally was able to come back as everything broke on me, which became a time consuming process of unwinding things, but I think that also comes down to thorough testing of anything that's getting merged. To keep this on-topic though, I think that if we're going to change the way that branches and releases happen, that @sorin-ionescu needs to sign off on whatever that change is going to be.

All that being said, if we are going to change the branching strategy, I need more information on how release management is going to be handled before I can comment. Is this a traditional "agile" workflow with sprints? Are features being cherry picked for merge or is this a lump sum dump from one branch to the next? If it's a lump sum dump, is there a "code freeze"?

[johnpneumann]

@indrajitr @jeffwidman @facastagnini - Thoughts anyone?

[belak]

I agree with doing our best to keep a clean log graph. Would it be acceptable to aim for a clean graph on one branch (potentially develop) and have the master branch pull in features deemed stable from there? It would unfortunately mean merging most patches twice, but it may be a worthwhile tradeoff.

Alternatively, we can take snapshots of the develop branch, but that would probably require a feature freeze period and I'd like to avoid that if possible.

If we manage to reach an agreement (and that means everyone who weighs in needs to agree with the plan, and isn't making any concessions) between most of the other contributors before we get a response from Sorin (it's been more than 3 months since he's been around) I would feel alright implementing it. But, aside from that or Sorin making a decision, I would not feel comfortable moving to a different way of managing this project.