-
-
Notifications
You must be signed in to change notification settings - Fork 635
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moving Towards 1.0 #874
Comments
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: |
I think it's still too soon to think about a v1.0 |
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... |
@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? |
Mods and stuff. |
Where is this donate button (and who does it go to)? |
What's wrong with redstone? A music box generated by NoteBlockStudio plays well, albeit somewhat slowly. More speed I guess? |
I don't think it's quite 100% compatible with Vanilla though, is it? |
Never knew '>' signified a quote.
But then how far back? There is still the issue of manpower. Maintaining three versions, especially with big potential conflicts, can be challenging. |
Oh yeah, comparators. You're correct. |
Well, the button used to be on the homepage. No idea where it is now. You can't enlarge the tip4commit button, can you? |
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) |
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. |
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/ |
For release "stable" version need fix many bugs of gameplay (I'll publish them in the bug tracker later) |
This is a pretty needed add on. It should be treated as First Class Priority and finished first. |
Updated at the top, can anyone comment? |
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. |
Makes sense. |
Anything done yet? |
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) |
I meant asking about having a stable branch :P |
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. |
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. |
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. |
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
Plugin API
Performance
Double the players with the same RAM and CPU.(Chunk sparsing completed)Usability
Vanilla commands basically replicated.What If We Get There???
What To Do Afterwards?
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).
The text was updated successfully, but these errors were encountered: