Moving Towards 1.0

[bearbin]

Ok, I thought of a new proposal for branching and everything else. I still believe that the stuff down at the bottom of this post is a good idea, but it's a long way off still.

For now, I think we should have a development branch where all dev work happens. Every week (perhaps every saturday or something) we would see if the branch has no major corruption/crash/huge resource consumption type bugs, then merge it into master.

The buildserver would only build from master, so hopefully the number of crash bugs and other major issues getting into users' hands.

What do you think?

Please ignore all below this line. It is old and might not have been updated for a while.

I was thinking about what it would take to produce a stable release, ready for "production". Our v1.0. This issue will contain what is needed to get there, and how we might go about when we stabilise.

Requirements

These are just some I could think of from the top of my head, so please give your own objectives, and tell me when some are completed.

Gameplay

• Redstone Compatibility
• Minecarts
• The End, and the Enderdragon
• Villagers, Villages and Trading
• The Nether, and Portals
• Command Blocks (optional)

Plugin API

• Stabilised and debugged.
• Documentation completed and a startup guide written.

Performance

• Double the players with the same RAM and CPU. (Chunk sparsing completed)

Usability

• User manual or installation and usage guide available.
• Vanilla commands basically replicated.

What If We Get There???

• Tagged stable releases in their own branch.
• Release branch for only stable stuff and bugfixes. Would be the default for downloads.
• Debian Package?

What To Do Afterwards?

• Performance!
• Modularise - performance and bugfreeness comes here.
• Test, test test. Get a testing framework and make it work.
• Cut LOC and complexity - refactor.
• Backport fixes to earlier versions - keep multiple stable versions for different minecraft releases?
• Standard keeping up with Mojang work.

Of course, these are just my thoughts for what we might do - please say what you think about this issue (and debate if we're actually going to reach this point in the first place).

[worktycho]

Just on the branching model. To minimise workflow changes I'd say we should go for the git workflow model of master is current dev version and most stable release is in a branch called release. Its basically the same but you don't have to switch where the pull requests go. If we do go for back porting fixes a separate branch per major release workflow would also be preferable.

I'd also say we need a way to tell what version your running, helps with a lot of things.

Also:
One thing to add to What To Do Afterwards?:
Modularise - Unit testing and performance benchmarks are basically impossible as you can't break off bits of the code.

[NiLSPACE]

I think it's still too soon to think about a v1.0

[tigerw]

Yes, we need more xofts. @Bearbot and @bearbin sets very long term goals.

---

• Backport fixes to earlier versions - keep multiple stable versions for different minecraft releases?

Please no, what's wrong with people upgrading their clients?

---

Even if we get more contributors to make this goal possible, the PRs still need to be reviewed by xoft, who has limited time. We need an incentive for him. Perhaps, if MCS really gains popularity, @FakeTruth could consider enlarging the 'Donate' button...

[bearbin]

@worktycho Thanks for the suggestions, adding them now. The branching model idea is great too, but AFAIK you can change the default branch on GitHub?

[bearbin]

Please no, what's wrong with people upgrading their clients?

Mods and stuff.

[bearbin]

@FakeTruth could consider enlarging the 'Donate' button..

Where is this donate button (and who does it go to)?

[tigerw]

What's wrong with redstone? A music box generated by NoteBlockStudio plays well, albeit somewhat slowly.

More speed I guess?

[bearbin]

I don't think it's quite 100% compatible with Vanilla though, is it?

[tigerw]

Never knew '>' signified a quote.

Please no, what's wrong with people upgrading their clients?

Mods and stuff.

But then how far back? There is still the issue of manpower. Maintaining three versions, especially with big potential conflicts, can be challenging.

[tigerw]

Oh yeah, comparators. You're correct.

[tigerw]

Well, the button used to be on the homepage. No idea where it is now.

You can't enlarge the tip4commit button, can you?

[bearbin]

But then how far back? There is still the issue of manpower. Maintaining three versions, especially with big conflicts, can be challenging.

Probably just one or two, and it would just be cherrypicking bugfixes really to the xofts happy. Like MS did with XP 😃 (not for ten years though)

[worktycho]

I'd say the release branch(es) should be bugfix only. I don't think you can change the default branch in github but most projects that follow this model have dedicated download packages and work on the principle that anyone who has made it all the way to the repo probably wants the latest and greatest version.
Even if we're not ready for a 1.0 we might want to prep a 0.1 beta.

[bearbin]

Well, the button used to be on the homepage. No idea where it is now

Here's a good new button URL - (although there aren't auto donates to everyone) gittip shows all the contributors: https://www.gittip.com/on/github/mc-server/

[axisd]

For release "stable" version need fix many bugs of gameplay (I'll publish them in the bug tracker later)

[pikachu784]

This is a pretty needed add on. It should be treated as First Class Priority and finished first.

[bearbin]

Updated at the top, can anyone comment?

[worktycho]

Just one proposal. Have a testing branch between develepment and master. So every so often (Say once a week at the moment) we merge testing to master and development to testing. This just stops code getting in to master without much testing by being merged just before we do the merge to master.

[bearbin]

Makes sense.

[SafwatHalaby]

Anything done yet?

[tigerw]

Some things, sort of, but nothing fully/completely functional. (i.e. Portals work, but the world creation they do block a thread; redstone partially works, but some things are broken or unimplemented)

[SafwatHalaby]

I meant asking about having a stable branch :P

[yangm97]

I feel like this could speed up development while having a equally, maybe more stable branch. Instead of doing in-game testing for each PR, the development branch would get updated with (finished) features in need of testing.

It may be a good idea to have public builds from the dev branch too, so those who like living in the bleeding edge can report real world issues that could go unnoticed by developers testing PRs individually.

The weekly release cycle seems reasonable to me. Also, what you described (or what I understood from it) looks pretty much like Git Flow.

[ghost]

Well, the state of the project is that we have too many unfinished / missing functions for make an stable version. We can do a version freeze, so we can focus on 1.9 1.10 support 1.11 support. (1.8 has in my opinion too many differences from the later versions) and make an stable version for that, we can go for supporting new protocols in development.

[SafwatHalaby]

We've actually already tried a freezing / branching model for a while and it wasn't productive at all to development. There wasn't - and still isn't - enough developer power to meaningfully maintain several branches, and the "frozen(testing)" branch and the "stable" branches practically lagged behind forever, and everyone kept using master.

Funnily enough, the frozen branch was often less stable than master, because so many bugfixes were making it into master and not into the freeze, and no one had the time to meaningfully patch them back into the freeze, so master was the most stable. I think that stable / testing / frozen branches are mechanisms that only work well past a certain threshold of stability + manpower. Typically new commits have a high potential to make things less stable, but we were at a too volatile stage and most commits actually made master's stability better, and I think this is still the case to some extent.

As long as we're low on manpower and/or till we reach a certain level of stability, this won't really work well.