| Newsgroups |
gmane.comp.audio.supercollider.devel |
| Message-ID |
<CAB_zQYuqeRz0tQOjKkKsxLYwnev96OUc2=oTY=1E8Y9-UAO-gg@mail.gmail.com> |
> for 3.10 i resolve to be much less lenient about the deadline than i was
for 3.9.
Hurrah!
> 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.
Can I ask, for purposes of documentation, what reasoning we could use to
make future conversations smoother? The git workflow and guidelines page
currently reads:
> The current release branch (like 3.9), to which only bug fixes can be
merged. (Features will occasionally be merged into release branches if they
are considered critical for that release.)
Maybe we should have a sentence like: "A bug fix may contain a new feature
if the feature is minor, and if implementing the fix without this feature
would require additional work."
Btw, this also brought to light that the explanations of "patch" and
"feature" may not be clear enough. I think the documentation should include
a few sentences on that.
-Brian
On Thu, Feb 8, 2018 at 1:34 PM, <nathan-PB1wun9k+p9Wk0Htik3J/[email protected]> wrote:
> 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/fa
> cilities/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/
>