Nuke the unneeded branches and make a new versioning system

[Nathan2055]

I have failed in my attempt to leave the project. So, I have another proposal that might hopefully garner more support than the one that caused me to (not)leave.

My new idea is simple, we nuke the develop and beta branches and just have master. When we want to push, we make a tag. This would require some slight modifications to the existing push scripts, but nothing too major (I've abandoned my Java thing, seems easier to avoid the war and use the Python one). I really think this would be a help in removing clutter. Any comments?

[theopolisme]

Then how do maintain the separate beta and master builds? And what about the develop/feature builds?

[Nathan2055]

@theopolisme - We make a new tag every time we push a build.

[hasteur]

2 tags. Most Recent Tag and Most Recent - 1 Tag.

The Most Recent tag is almost always the beta tag. It represents the mostly done, but still not ready for "production" code. Most Recent - 1 Tag represents the production version which has been the beta for a while and nobody reported problems so we can go ahead and promote it to main (where users who aren't primarily interested aren't looking)

Also, if a tag royally screws up a deployment, we revert back to the previous tag and delete the failed tag.

[hasteur]

A tag is just a pointer to a specific version of the code.

[wikipedia-mabdul]

@hasteur and how to handle small important bug fixes for the master branch (the stable build)?

[theopolisme]

^^ e.g., the issue we had previously with the gadget file structure. While obviously we hope it won't happen again, things happen, and the system we had in place did handle it correctly -- that's something that should be kept in mind.

[hasteur]

@wikipedia-mabdul: Small important bugs to the stable (and why was the bug not found when beta testing) would be as simple as checking out the tag, applying the bugfix to the tag version, subtagging the tag (0.1.1.432), merging the bugfix to the trunk (because it should be broken there as well), creating the new beta tag (0.1.4)

[theopolisme]

@hasteur i guess the thing is, that sounds -- even from just the way you explain it -- more complicated than simply fixing the master and applying the patch retroactively to develop. [just my 2¢]

[hasteur]

@theopolisme If you think managing 3 developers is hard, just wait till you get ~30 developers all doing changes and having to be the gateway to the "Blessed Source".

http://sethrobertson.github.io/GitBestPractices/#workflow has some examples of workflows

[theopolisme]

"just wait till you get ~30 developers all doing changes"

Not only am I highly skeptical that that day would ever come (just look at twinkle's contributor stats -- and it's arguably the most widely used script on Wikipedia), but I also would like to note that we are, apparently, following a workflow -- http://nvie.com/posts/a-successful-git-branching-model/ (the only differences? 1. we aren't tagging our releases in master, but i have no problems with doing that, and 2. we don't create release branches ahead of the fact, we use beta).

[enterprisey]

I didn't know we were following a workflow...

Why aren't we tagging our releases, again? It seems like it would be a little bit more organized.

[theopolisme]

The only reason tagging our releases would make sense is if we did everything in one branch, which we are not currently. Right now, our rapid release schedule (and it sure is rapid...that reminds me, actually, it's about time to push the beta to master) works by having a feature --> develop --> beta --> master workflow, with hotfixes at any point. But I'm not averse to change, if there is good reason for it.

[enterprisey]

Alright, thanks.

[theopolisme]

Closing as stale. Reopen if new discussion.