Vega-strike-engine-source: Historical Branches

[BenjamenMeyer]

We need a way to provide updates to existing releases. Currently we have master and an 0.5.x series. I propose the following:

• Git Tags are used to mark each specific release.
• Each series (0.5.x, 0.4.x, etc) gets its own maintenance branch.

To do this, we need to do the following:

• [ ] Define what release series we are supporting
• [ ] Create a branch for each supported branch
  
  
  
  • [ ] Rename the 0.5.3 branch to 0.5.x
  
  
• [ ] Create tags for each release

If we can get historical releases (0.4.x, 0.3.x, etc) tagged that'd be great, but it'll largely depend on how the conversion from Subversion took place and whether it was an import with historical changes or a straight import of the Subversion Head. (Hoping the historical changes were kept.)

[BenjamenMeyer]

One can create a branch from a tag with:

$ git branch <branch name> <tag name>

And then push it via since the tag and branch have the same name:

$ git push <target> refs/heads/<branch>

However, to do this on the org's repositories requires certain permissions to do.
I can't see it how to do the same thing in the GitHub UI.

[royfalk]

My vote is to not support older versions with one exception: Provide a way to convert savegame files if these change.

My reasons:

1. It takes resources we don't have. An hour spent on this is an hour not spent on a new feature or bug fix to master.
2. Unlike commercial/mission critical products, we don't have paying customers and there's no expectation of such support. Players are far less sensitive to breakage in a new release and have little incentive to not upgrade.
3. It isn't fun. We're all volunteers and we'll want more to contribute. I doubt there's anyone here who wants to maintain crufty old code when there's shiny new features to code.

[BenjamenMeyer]

@royfalk in general I agree; though I think we should probably keep 1 historic branch active (0.5.0) in case we need to do sub-releases between release. That way we can mess up master in ways that leave us unable to release for a period when necessary (the exception not the rule); some changes like restructuring stuff might require that. We can effectively make branches Read-Only when we're done with them (the next release).

So for example, right now we'd have an 0.5.x branch running while we work on master. If we need to cut 0.5.4 we can do so from that branch and bring any changes over we need from master, but it'd mainly be about fixes to 0.5.3. master effectively becomes 0.6.x. When we are ready to cut 0.6.0 we make the branch 0.6.x, cut 0.6.0, and then stop taking PRs against 0.5.x (thus making it read-only since merges are gated). If another group was reliant on 0.5.x then we could work with them to either (a) (preferably) get them up to 0.6.x or (b) get someone from their group to help maintain 0.5.x if they can't.

[royfalk]

That's exactly what I meant.

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: Benjamen Meyer [e-mail]
Sent: Thursday, April 9, 2020 5:08:54 PM
To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Cc: Roy Falk [e-mail]; Mention [e-mail]
Subject: Re: [vegastrike/Vega-Strike-Engine-Source] Historical Branches (#59)

@royfalkhttps://github.com/royfalk in general I agree; though I think we should probably keep 1 historic branch active (0.5.0) in case we need to do sub-releases between release. That way we can mess up master in ways that leave us unable to release for a period when necessary (the exception not the rule); some changes like restructuring stuff might require that. We can effectively make branches Read-Only when we're done with them (the next release).

So for example, right now we'd have an 0.5.x branch running while we work on master. If we need to cut 0.5.4 we can do so from that branch and bring any changes over we need from master, but it'd mainly be about fixes to 0.5.3. master effectively becomes 0.6.x. When we are ready to cut 0.6.0 we make the branch 0.6.x, cut 0.6.0, and then stop taking PRs against 0.5.x (thus making it read-only since merges are gated). If another group was reliant on 0.5.x then we could work with them to either (a) (preferably) get them up to 0.6.x or (b) get someone from their group to help maintain 0.5.x if they can't.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/vegastrike/Vega-Strike-Engine-Source/issues/59#issuecomment-611547958, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQWBEBOCWZ6VY565WAAVG3RLXJHNANCNFSM4MEM6RJQ.

[BenjamenMeyer]

We already have all the branches we need. It may be useful to tag all the old releases.
To do so, we'd need to find the git hash related to each release, and then do:

$ git tag <release name> <commit hash>

or do similar in the GitHub interface. I'm not advocating we build releases for those tags; just mark them to make them easy to find. Finding each release will require going through git log to find each release and recording the name and associated git hash.

We presently have the following git tags:

0.5
0.5.1
0.5.1-rc3
0.5.3
V0.6.0-alpha
V0.6.0-alpha2
V0.6.0-alpha3
V0.6.0-alpha4
v0.5.1-rc1
v0.5.1-rc2
v0.6.0
v0.6.0-alpha5
v0.6.0-alpha6
v0.6.0-alpha7
v0.6.0-beta1
v0.7.0
v0.7.0-alpha1
v0.7.0-alpha2
v0.7.0-alpha3
v0.7.0-alpha4
v0.7.0-beta1
v0.7.0-beta10
v0.7.0-beta11
v0.7.0-beta12
v0.7.0-beta13
v0.7.0-beta14
v0.7.0-beta2
v0.7.0-beta3
v0.7.0-beta4
v0.7.0-beta5
v0.7.0-beta6
v0.7.0-beta7
v0.7.0-beta8
v0.7.0-beta9
v0.8.0-pre-alpha0

New releases automatically get tagged through the GitHub Release mechanism. So this is only for historical purposes to help find old release data.