Giving MCServer a version number
#11
because then we'd have several different executables of the same version (on builds.mc-server.org)
Reply
Thanks given by:
#12
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.
Reply
Thanks given by:
#13
You do know that we did that when we were still using google code? We never released new builds, so people started complaining.
Reply
Thanks given by:
#14
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.
Reply
Thanks given by:
#15
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).
Reply
Thanks given by: sphinxc0re
#16
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?
Reply
Thanks given by:
#17
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.
Reply
Thanks given by: tonibm19 , sphinxc0re , LogicParrot , Serial
#18
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
Reply
Thanks given by:
#19
When will be the time that we switch to this branching model?
Reply
Thanks given by:
#20
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?
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)