Vega-strike-engine-source: Stable vs Unstable Releases

[BenjamenMeyer]

I don't know what the devs have done in the past (perhaps @Loki1950 can provide some insight); but regardless we can set our way going forward. The question was brought up in #76 (or hinted at at least by @evertvorster) regarding stable vs unstable releases.

Background: There's multiple methods of doing releases. Two popular ones are:

• Model A: Have a master branch, split off a release, and then keep moving forward. Master is always prestine but unstable in nature. The release branches only get what is intended for that release.
• Model B: Master branch is prestine and is released using one version (f.e odd version numbers); branches are cut for release versions (f.e even version numbers), and the two roll together. For example 0.7.x (master) would roll with the stable releases of 0.8.x; sub releases would always match up.

We've thus far been planning on Model A. We could switch to Model B. Model B would involve more on-going work to sync the two branches and maintaining version numbers, etc.

Thoughts?

[BenjamenMeyer]

We've been following Model A. Master gets updated to the next release version when we cut a release. The update of the version number is mostly to ensure we don't forget and is normal when cutting a release. We could migrate to Model B by simply not cutting release branches of odd version numbers (0.7, 0.9, etc.) without changing much at all.

I think historically they might have just used tags for releases... though that's not really a fair question as most of the history was in Subversion where a branch/tag is mostly the same thing and in Git they're very very different things.

Any how...just raising the question of what folks want to do or see as practical.

[stephengtuggy]

I would prefer to have every branch be a stable branch. But maybe that's just me.

[Loki1950]

In the past releases where just tags on the master branch in svn @stephengtuggy we are not making mil spec systems here ;)

[evertvorster]

@stephengtuggy, In my experience, it is good to have two avenues of development. One for the crazy will-try-anything crowd, and one for the crowd that likes stuff to work.

Model A here, has the master as the development, or crazy ivan place, and every branch is where master have settled down after some feature implementation. It's compact and to the point. I like it. Every branch is a stable branch. If it's not stable, it's in master.

Model B, you have master, dev-head and stable-head branches. Master sort of hangs around in limbo with this method.

So, that was my understanding of Model A, and Model B. So far, everyone has been saying we have been following Model A, but with a development, stable and master branch, it looks much more like a Model B to me. Am I wrong? Where? If we want to be in Model A, it would mean dissolving branch 0.7.0, and developing on master. Once we are happy that everything that we could think of in this round has been implemented, and tested to be working, cut a new stable branch.

Admittedly, that sounds like a much faster paced thing than what we have now.

[BenjamenMeyer]

So our present branching:

• Master is current development work for the next release cycle.
• Branches are used for each release so we can stabilize, feature freeze, etc and then release; and if necessary apply fixes.

Ideally a branch would only be bug fixes for a given release, but there will always be some stabilization going on before each release branch can be released.

Now we're probably not following this strictly yet because we're getting a handle on things and 0.6.x got branched at an irregular point. But that's the goal.

Once 0.6.x is released we'll let master bake a little with 0.7.x as we get a few thing done, but then feature freeze and branch it. At which point master will become 0.8.x and we'll fix up 0.7.x for the release. It should be less effort at that point since we'll already have a release under our belt and the tooling should all be there. Right now we're rebuilding all the packaging functionality on top of figuring out the code, etc.

[stephengtuggy]

In the past releases where just tags on the master branch in svn @stephengtuggy we are not making mil spec systems here ;)

Good point. Haha

[nabaco]

I'd like to highlight an important point here. We're are not producing a product that people rely on in production. It's not an operating system or anything else that people will be extra careful to upgrade.
So in that regard, I see our release branch very short lived, until the next release branch is out. Or in other words, similar to what @evertvorster said, a release branch is there for people to have something at hand until we develop the next version.
The only case, in my opinion, when we'll consider extending a branch's life is:

• the next release branch drops support for a version distro version
• the next release branch introduces a breaking change for modders

[nabaco]

Additionally, for the brave that insist playing on master, and don't have AUR, we can have nightly builds on master, which will supply them with the packages. That'll be our "unstable" release.

Btw, @BenjamenMeyer, for the 0.6.x branch i think we can already have an Alpha build for a wider audience to begin testing

[BenjamenMeyer]

@nabaco build wise I agree. feel free to mark an alpha release. We still need to figure out the infrastructure to distribute it.

[BenjamenMeyer]

We've had enough releases now we probably know what we're doing. Closing this.