What about non-critical bugs?
I think everything should be merged with master except critical bugs like crashes, etc.
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 it
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.
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".
(05-09-2015, 09:17 AM)worktycho Wrote: [ -> ]I have evidence
.
But it was probably a mistake.
Whoops. Well, my apologies; didn't mean to do that.
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.
We can try that. How about a week?
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.
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.