+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Discussion (https://forum.cuberite.org/forum-5.html)
+--- Thread: Giving MCServer a version number (/thread-1847.html)
RE: Giving MCServer a version number - xoft - 03-29-2015
because then we'd have several different executables of the same version (on builds.mc-server.org)
RE: Giving MCServer a version number - tonibm19 - 03-29-2015
My idea was to use builds.mc-server.org as beta/testing downloads and github releases tab would include zips of the latest stable release for win&linux.
And only use version number as reference for releases, no integrated into the api or MCS source.
RE: Giving MCServer a version number - NiLSPACE - 03-29-2015
You do know that we did that when we were still using google code? We never released new builds, so people started complaining.
RE: Giving MCServer a version number - tonibm19 - 03-29-2015
Yes but they would still have experimental builds at jenkins.
A new release at github would include a lot new things.
Ex:
-Added written books
-Fixed bug blablabla
-Added basic blablabla support
-Fixed deadlock blablabla
I meam, jenkins for every commit and github releases for every X time (1 month for exemple) and stability tested.
RE: Giving MCServer a version number - worktycho - 03-30-2015
There was a small amount of discussion on this last September. If I remember correctly the issue with releases was at that time that it was more important to allow new features to flow through to the released version, until we had a reasonable level of comparability with the main server. If we have now achieved that goal it might be worth starting a release schedule. I'd be willing to organise releases if everyone was willing to agree to follow the branching model. (No commits to the release track).
RE: Giving MCServer a version number - sphinxc0re - 03-30-2015
Oh, I like that idea so much. Do you need help the release schedule? Or should we make a Google doc for every schedule and the community suggests, what to put in and what not?
RE: Giving MCServer a version number - worktycho - 03-30-2015
The general approach would be to split the repo into three tracks, release, testing and trunk. release track would not have any changes applied directly, testing would only have bugfixes merged not features, and trunk would be where features would be added. Then every few weeks/months we would take the trunk and make that the new testing and make what was in testing the new release. The actual planning of features would continue as we are now, its just they would get more testing and bugfixing before reaching release.
RE: Giving MCServer a version number - sphinxc0re - 03-30-2015
Okay but if we do that I would suggest another website redesign. I know that sounds silly but the current website is not designed for such a software model. I mean it doesn't have categories or so and we would need some kind of dev-blog. In case we're making one, I would volunteer for that
RE: Giving MCServer a version number - sphinxc0re - 04-13-2015
When will be the time that we switch to this branching model?
RE: Giving MCServer a version number - worktycho - 05-08-2015
Disscusion in https://forum.cuberite.org/showthread.php?tid=1910 has indicated that its probably important that we go for a release branch. @xoft, @NillSpace do you or anyone else have any objections about implementing the three track release model?
@bearbin, if we went for it would you be ready to sort out the build server to manage the additional builds?