Skip to content
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

Closed
JohannesLorenz opened this issue Jan 19, 2019 · 12 comments
Closed

Stable branches #4780

JohannesLorenz opened this issue Jan 19, 2019 · 12 comments

Comments

@JohannesLorenz
Copy link
Contributor

JohannesLorenz commented Jan 19, 2019

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:

  • We're rejecting developer's contributions, even if they're tested well, arguing that stable-1.2 has feature freeze. Developers get disappointed because features they develop now will be released in maybe 2 years. Developers may even start forks that will never be merged 💔
  • We're prioritizing in a strange way. E.g., we're delaying stuff like CALF updates, which will fix multiple effects, or Lv2, which bring us up to 1200 plugins, because of minor issues in one single plugin (like the SF2 player issues).

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

  • Bugs where clipping occurs that can damage speakers or the listeners
  • Bugs that remove files from your hard disk (seldom!)
  • Bugs that allow hackers to exploit savefiles to attack your PC (IIRC we never had that)

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:

  • 👀 Don't release anything until all 1.2 issues are solved; Don't allow features from master to become stable for 1.2.
  • 👍 Release on a regular base (e.g. every 3 months), even with open issues. Stable branches are abandoned every release.
  • 🎉 Other option, please specify in a comment
@zonkmachine
Copy link
Member

and even then, 1.2.1 is announced

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 don't expect it for the next 3 or 4 months,

I was rather hoping to see this released within a month.

@ghost
Copy link

ghost commented Jan 19, 2019

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"
It's not a literal quote, but close.

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?

@musikBear
Copy link

Honestly i DAILY ask new users, with typical VSTs problems to upgrade to RC7!
Problem fixed!
Further, 1.1.3 can make very strange issues on some setups of win10, that hits usage of:

  • MIDI-hardware
  • VST
  • UI scaling
  • Even issues with SDL

I have pleaded for a byline for 1.1.3 "not win10 friendly" or similar. That was ignored.
So now new users dl 1.1.3, install, get flaws fault and hickups, and carry theres woes over on Forum, where an idiot tell them, that the DL that is listed as stable is not running on all types of win10, and they should !upgrade! to an RC??!?? (wtf..

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!
So RC7 has bugs??!
ALL sw has bugs! Release Now!

@Cangle50
Copy link

1.1.3 never even worked on my windows 10 - 32/64 bit PC.
That is why I use 1.2.0-rc6 for now because rc7 which I refuse to use has a pitch bend bug #4625 and am waiting for rc8 to see if it has been fix.

@JohannesLorenz
Copy link
Contributor Author

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

  1. either have stable-1.2, stable-1.3, stable-1.3.1, stable-1.3.2 etc in parallel to let any of them get stable separately. Sounds a bit like a branch hell, but maybe it will work well.
  2. have only one stable branch at a time, merge it back after the release and then start the next one.

Aside from these two options (and the current option), does anyone have another idea? Let's collect ideas and then make a vote?

@ghost
Copy link

ghost commented Jan 21, 2019

I'm in favor for having a separate stable branch. However it's implemented (per release version or global).
I think if we want to go that route it would be handy to have a portable version of lmms we can build. (definitely not for the next release, but maybe we can put it in master)

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.

@musikBear
Copy link

One stable branch.

@BaraMGB
Copy link
Contributor

BaraMGB commented Jan 27, 2019

There will never be a perfect time for releasing. Just release 1.2

@JohannesLorenz
Copy link
Contributor Author

I turned this into a poll. If you haven't voted yet, please do now.

@zonkmachine
Copy link
Member

zonkmachine commented Feb 9, 2019

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.

@JohannesLorenz
Copy link
Contributor Author

I'm closing this. The poll does not seem representative enough anymore.

@dvzrv
Copy link

dvzrv commented Feb 16, 2019

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).
This will ease confusion and streamline things a little again.
Also: One stable branch. I don't think there are enough developers to keep a multibranch thing alive.

Best of luck!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants