Mtasa-blue: Decide branch structure for 1.6

[qaisjp]

There have been a few discussions relating to a new temporary branch structure to support the development & testing of 1.6 alongside the maintenance of 1.5.7.

We must decide on a branch structure (if any change) that will going into effect when 1.6 is in development, i.e. after 1.5.7 has released. This blocks the release of 1.5.7.

This is a placeholder issue to ensure we do not forget to continue this discussion & to help ensure this discussion continues in the open.

More to come, soon.

[Woovie]

Having researched many branch methods, I found this one personally to be a very good system: https://nvie.com/posts/a-successful-git-branching-model/

[botder]

The branching method suggested by Woovie looks fine.

[patrikjuvonen]

I agree, I think Woovie's suggestion should be a good choice for us.

[qaisjp]

Just collecting a summary of our discussions here...

@Jusonex suggested:

Also considering the other problems we’ve been running into recently (e.g. the ZERO_MEMORY issue), my suggestion is:

• Release 1.5.7 as soon as possible with all hackfixes in it
• Branch a develop branch from master and commit only hotfixes to master
• Freeze feature addition temporally and fix all issues: This involves rewriting great parts of the hooking stuff and getting rid of inline assembly as much as possible (at least for Multiplayer SA; Game SA isn’t the problem atm). Also remove all occurrences of ZERO_MEMORY
• Merge in network compatibility breaking changes (e.g. opus voice, perhaps custom-train-tracks), maybe some critical other PRs
• Release 1.6 beta (Multiplayer SA fixes probably require more testing)
  
  
  
  • Re-establish a test team (I assume a test team works better than just asking the community), maybe assign additional ranks in the forums
  
  
  • Create concrete test plans
  
  
• Release 1.6 stable

@qaisjp says (paraphrasing/summarising overall thoughts here):

I feel that having a separate develop branch would be good, as it allows us to keep our non-finalised features that are currently being tested (nightly stream), away from "production" (release stream).

@Jusonex says that the 1.6 branching would only be temporary, and that:

I'm not sure if generally having a develop branch is a good idea - in that regard I share sbx' fear that people won't test it continuously on long term. But if we also take this as a test run and it works well, I'd be open to keep the system

@sbx320 has some concerns:

there's either going to be a largely untested master or a largely untested develop branch, depending on whatever is the current nightly

@ccw808 asks:

Would the develop branch be able to connect to public servers?

@Jusonex and @qaisjp say something like:

Yes, as long as we didn't introduce breaking net changes

@sbx320 responds:

still not that much of a fan as it just causes weird git history things (merging doesn't work properly I think)

apart from that I'd just prefer keeping master as "current development" and going with a release branch (rather than develop + master = stable), but that's just a matter of preference I guess

@qaisjp responds:

This can be fixed by either:

• writing fixes on release, and merging release into develop
• or, writing fixes on a hotfix branch, then merging the hotfix branch into both release and develop

@sbx320:

yeah I don't like the full git flow for our scale... it just complicates stuff

@qaisjp:

Yes, I’ve just looked at it again now, and it separates release branches and master into two (or more) separate things. I guess we want to merge that functionality into one.

@qaisjp:

Oh, I realise that we do need to decide on this before we release 1.5.7

@sbx320 :

We probably should

@qaisjp suggests:

Currently: build server decides what revision is pushed out.

Future:

• develop is latest nightly, can access latest servers. Equivalent to nightlies today
• master (or release) determines what is on the release stream.

Advantages:

• master can receive hotfixes without also receiving unstable develop features

Today:

• Majority uses old commit of master
• some use HEAD of master

Future:

• Majority use master
• some use develop

@sbx320 responds:

so similar to xp/vista vs master stuff today?
(where xp/vista only gets updated once in a while)

@Dutchman101 responds:

i understand it better now, that could be a good concept..
i just wonder, are you planning to slowly move develop features into master, as they become tested? without a new release
or would you rather pick up the pace (release every 3 months) to guarantee everyone remains happy

@qaisjp responds:

somewhat similar to xpvista, minus the features. I would prefer to release more frequently.

Doing detailed releases involve a bit of a work but there's a couple things we can do to reduce the amount of effort required

Today @qaisjp noted:

I think [using a new function from 1.5.6 r12345 or 1.5.7 is relevant], because we aren't able to iterate and improve our work. We need to have that flexibility to change an API after people have tested it

@sbx320 responded with a very good point today, in #mta.dev:

simply define that any API that isn't in a release is subject to being broken at any time

(This works excellently for updates to our Lua API.)

---

I apologise if I have missed some conversations or missed some key points. I will happily edit this comment.

---

So, basically, there's one thing here: are we going to do @Jusonex's suggestion [temporarily for 1.6 beta only]?

If not, I'm happy to drop the entire conversation, because it seems like I'm the only one that is concerned with incomplete features making it into production (release, non-nightly) builds.

[Dutchman101]

So, basically, there's one thing here: are we going to do @Jusonex's suggestion [temporarily for 1.6 beta only]?

If not, I'm happy to drop the entire conversation, because it seems like I'm the only one that is concerned with incomplete features making it into production (release, non-nightly) builds.

That's probably because it is a very rare event; only done for a good reason, by (or with the approval of) @ccw808 who carefully evaluates the critical need for "all players to have that version"

Rare (for the auto-updater): happens on average 1 to 3 times during the lifespan of a release
Rare (for main download): only happens to test stability for a few days, in preparation of either raising stable revision (in the way of above, which happens 1 to 3 times a release) or highest supported minclientversion for servers, due to a critical need for fair play

You can say that the current system regarding this can be awkward at times, but in real-life situations for these reasons it never tends to result in trouble.

[qaisjp]

Closing this because it's clear that nobody except me is concerned about non-production-ready features making it into production builds.

1. I still think we should just do releases instead of forcing auto-updates. The fact we can do this makes the whole versioning system worthless.
2. We should actually write down our unwritten policy, if it exists at all, of making sure stuff in master is safe for release (or otherwise marked as "beta")