refactorings in minor versions

julian.rohrhuber-QYZGCWsIODmAF8UT6DzBU6xOck334EZe@public.gmane.org Thu, 8 Feb 2018 18:15:10 +0100

Newsgroups	gmane.comp.audio.supercollider.devel
Message-ID	<[email protected]>

It seems to me that we have just stumbled upon a kind of deadlock in our new workflow. The workflow is intended to make it easier to determine which things should be done when.

If I understand correctly, new features are something that should happen only in major releases, like 3.9 to 3.10.

The problem is that when you refactor code properly, you definitely will create new methods. If those methods are banned, because they imply features, we have to postpone refactoring to major releases. Personally, I find this adds a major hurdle: you have to first find a workaround, before you then find a lasting solution. t can even encourage bad coding style. I agree that “proper” features should be retained, but the problem remains.

Here is the last message on github that I wrote:

https://github.com/supercollider/supercollider/pull/3499#issuecomment-364158950

>I don't mean this as an argument for "let's follow rules for the sake of it". I just want some sort of stability and agreement so we can stop splitting hairs. If we never establish any firm rule whatsoever, there's no chance of that.

sure, I'm fine with rules. I've tried to find the rule you are alluding to, but rereading the guidelines, I couldn't find it. It's a lot of stuff, maybe I've overlooked it.

>For example, we have already spend more time here than it would take to just wait until 3.10 and swap out the method.

We need to keep the flow. 3.10 is scheduled for early July, and I wouldn't want to wait so long. But let's move the discussion to the mailing list. (done just now.)

signature.asc (application/pgp-signature, 833 B)