Giving MCServer a version number
#51
What about non-critical bugs?
I think everything should be merged with master except critical bugs like crashes, etc.
Reply
Thanks given by:
#52
Seems sensible.
Reply
Thanks given by:
#53
I'm creating a new label, for issues that should be fixed on testing.

If the name I picked was horrible, feel free to change itTongue
Reply
Thanks given by:
#54
Good.

Also, what are we going to do about the website? I think that we should move the master builds off the home page, with only stable builds on the home page and testing and master builds on a separate page.
Reply
Thanks given by:
#55
To encourage more testers, perhaps the testing should remain on the homepage below stable, with a message like "Feeling adventurous? These builds provide newer features but are a bit less stable, if you find any problem with them, you can report...".

Renamed the label to "Important".
Reply
Thanks given by:
#56
(05-09-2015, 09:17 AM)worktycho Wrote: I have evidenceConfused.

But it was probably a mistake.

Whoops. Well, my apologies; didn't mean to do that.
Reply
Thanks given by:
#57
We can have this policy: Never rotate as long as there are open "important" labels. Rotate only when there haven't been "important" labels for some time.
Reply
Thanks given by:
#58
We can try that. How about a week?
Reply
Thanks given by:
#59
A friend of mine is currently working on a small (or large) secret project, and he is currently using a new version system. Maybe we can wait a few hours (or days) and look what he did.
Reply
Thanks given by:
#60
Maybe, we can create at every end or begin of a month a new stable release.
So the stable release of this month if we use the format "year.month", would be: "15.05" for example, the stable release of june would be "15.06".

This allows easy recognition of the "release date" of this build. And not random like 0.1; 0.2 etc.

The question is, if this stable release should be scheduled for the same date in every month, or should it be individual created "if it's ready".

I think it should be scheduled for a specific date in every month. For example the last day in every month. So we can say, one week before this last day in the month, were the stable will be released, is feature freeze in the stable branch, and only fixes can come up in this branch, to guarantee stability. And finally the stable release can be pushed. After this, the schedule can begin again.
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)