Giving MCServer a version number

xoft · 03-29-2015, 08:32 PM

because then we'd have several different executables of the same version (on builds.mc-server.org)

tonibm19 · (This post was last modified: 03-29-2015, 11:30 PM by tonibm19.)

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.

NiLSPACE · 03-29-2015, 11:32 PM

You do know that we did that when we were still using google code? We never released new builds, so people started complaining.

tonibm19 · 03-29-2015, 11:36 PM

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.

worktycho · 03-30-2015, 12:53 AM

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).

sphinxc0re · 03-30-2015, 05:07 AM

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?

worktycho · 03-30-2015, 06:08 AM

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.

sphinxc0re · 03-30-2015, 07:09 AM

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 Smile

sphinxc0re · 04-13-2015, 07:34 AM

When will be the time that we switch to this branching model?

worktycho · 05-08-2015, 07:40 AM

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?