search

cuberite / cuberite

A lightweight, fast and extensible game server for Minecraft
https://cuberite.org
Other
4.99k stars 635 forks source link

Moving Towards 1.0 #874

Closed bearbin closed 7 years ago

bearbin commented 10 years ago

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

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 commented 10 years ago

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 commented 10 years ago

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

tigerw commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

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

Mods and stuff.

bearbin commented 10 years ago

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

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

tigerw commented 10 years ago

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

More speed I guess?

bearbin commented 10 years ago

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

tigerw commented 10 years ago

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 commented 10 years ago

Oh yeah, comparators. You're correct.

tigerw commented 10 years ago

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 commented 10 years ago

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 :smiley: (not for ten years though)

worktycho commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

pikachu784 commented 10 years ago

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

bearbin commented 9 years ago

Updated at the top, can anyone comment?

worktycho commented 9 years ago

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 commented 9 years ago

Makes sense.

SafwatHalaby commented 9 years ago

Anything done yet?

tigerw commented 9 years ago

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 commented 9 years ago

I meant asking about having a stable branch :P

yangm97 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.