-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stable branches #4780
Comments
My intention with opening the 1.2.1 milestone was to get some lesser important issues out of the way for the 1.2.0 release to speed things up. That's all. If we don't want that later, then we'll remove it.
I was rather hoping to see this released within a month. |
On discord I've read one user recommend to another user to "install the unstable version because it is more stable than the stable version" Maybe a way to settle this is to compare the download statistics from lmms.io. How many downloads for 1.1.3 and how many for 1.2.0-rc7? The former should outnumber the latter by a wide margin. If not maybe we should consider releasing despite the bugs we have. I'm not advocating to release right now. All I'm saying is if users start to ignore the beta label and use it like it was a released product, then what are we doing pretending it's still an RC? |
Honestly i DAILY ask new users, with typical VSTs problems to upgrade to RC7!
I have pleaded for a byline for 1.1.3 "not win10 friendly" or similar. That was ignored. My 2 cents would be to right now and here release RC7 as 1.2, and get rid of that pesty 1.1.3 "stable version" That is a bad joke! |
1.1.3 never even worked on my windows 10 - 32/64 bit PC. |
I think releasing RCs as full versions does not suffice, but we also need to give new features a chance to "also become stable". This means
Aside from these two options (and the current option), does anyone have another idea? Let's collect ideas and then make a vote? |
I'm in favor for having a separate stable branch. However it's implemented (per release version or global). It should make things easier for alpha and beta testers to download and test the "master" branch. If they can't find anything wrong, we can promote it to the stable branch. I'm surprised at the number of people in discord who are willing to do tests. In any case, if we want a stable branch, I don't think it's a developers only decision and with minor adjustments I think we can get enough testers on board so we can know when a feature can be upgraded to stable. |
One stable branch. |
There will never be a perfect time for releasing. Just release 1.2 |
I turned this into a poll. If you haven't voted yet, please do now. |
I don't see that 👍 and 👀 are mutually exclusive. There has been talks on changing the releases going forward but I basically missed that since I've been away for long periods. As for 👍 , features from master aren't going into stable-1.2 no. Maybe we should have kept the door open longer as it's taken such a long time to complete this, at least I think so, but now it's really feature freeze and 1.2 is going to be released pretty soon. |
I'm closing this. The poll does not seem representative enough anymore. |
Not sure what that means, but I can also only recommend to release now (from a packager point of view). Best of luck! |
Currently, we're not getting 1.2.0 finished. Looking at the open issues and the time we need to fix them (and the amount of new issues) I don't expect it for the next 3 or 4 months, and even then, 1.2.1 is announced. This has drawbacks:
A typical reply is "Stable must not contain any new bugs, so we need to solve them all now". I agree for security related bugs, i.e.:
For all other bugs, I'd say, leave them open. It's not that bad if a new release has some bugs. Firefox makes new releases fixes so often, marking all older releases as vulnerable. Does that hurt?
Our definition of "stable" is questionable. Somehow, the 1.2 features/fixes all got stable (by testing them for a long time). We could test 1.3 features the same way, but they'd still be rejected for 1.2, just because of "feature freeze".
Conclusion:
We need to release regularly and give new features a chance to get stable. We need a new definition of stable, e.g. let's say an issue that has been announced for stable tests and had no issues for 3 months is considered stable. Make new releases every 3 months, discarding all bugs (except for security bugs like the ones listed above).
We could even release every month. Again, look at Firefox...
Poll:
The text was updated successfully, but these errors were encountered: