Re: refactorings in minor versions

On 2018-02-08 09:15, julian.rohrhuber-QYZGCWsIODmAF8UT6DzBU6xOck334EZe@public.gmane.org wrote:
> 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.

hi julian,

i haven't been on the project as long as most of you have, but hasn't it 
always been the case that 3.x introduces new features and 3.x.x fixes 
bugs? it's still my fault that i didn't document this explicitly, but i 
was under the impression that this isn't anything new -- we're just 
moving way faster than before.

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

i am, in abstract, against refactoring in 3.x.x releases. in patch 
releases we should be playing it safe and touching only what we need to 
touch. if a bugfix is elaborate enough to require refactoring on the 
side, it has a greater risk of breaking, so it is safer to save it for a 
3.x. this is dependent on the urgency of the bug.

in this particular case i acquiesce and i'll let the killProcessByID 
method through for 3.9.2. it's pretty harmless. i wouldn't be happy if 
we let a dozen more small features through.

one option is to speed up the 3.x release cycle to 4 months. i'm 
impressed with our productivity so far this year and i don't think 
there's much harm in that. for 3.10 i resolve to be much less lenient 
about the deadline than i was for 3.9.


nathan

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/