* Re: Plan for the 5.9 branch
2020-02-18 19:40 ` dana
@ 2020-02-18 20:44 ` Bart Schaefer
2020-02-19 10:23 ` Daniel Shahaf
2020-02-19 10:32 ` Daniel Shahaf
2 siblings, 0 replies; 11+ messages in thread
From: Bart Schaefer @ 2020-02-18 20:44 UTC (permalink / raw)
To: dana; +Cc: Daniel Shahaf, Zsh hackers list
On Tue, Feb 18, 2020 at 11:41 AM dana <dana@dana.is> wrote:
>
> Right. All i'm really worried about personally are fixes for security issues
> and the type of regressions we normally correct in .1 releases.
At my $WORK we use the following approach, parts of which might be
overkill for zsh-workers, but presented in case worth discussing:
The current release is always a version number tag on the master
branch, there are not branches for numbered releases.
Each proposed change goes on its own branch created from master. This
is rebased on master if necessary before merging with other changes.
(In the zsh world this would probably mean creating a branch named for
a zsh-workers sequence number.) Critical changes (post-release
regression fixes, security issues, etc.) can go directly from these
branches onto master for immediate release if necessary, at which time
a new version tag is created on master.
There's a development branch onto which anyone can merge/push pretty
much anything, even if it's not on a proposed branch yet, to test
conflicts/interactions, get feedback, etc. This is sort of what we do
in zsh via vetting of patches on the mailing list.
Right before a release, a staging branch is created, which is the
master branch merged with whatever subset of the proposed change
branches are ready. This is like the zsh*-test-N versions we've been
publishing, it's used to QA the assembled changes before they go on
the master branch, but it allows us to pick and choose which proposed
changes actually go into a release if some are "more thoroughly
cooked" than others. Changes that result from QA get revision tags on
the staging branch.
For release, the staging branch is merged back onto master and a new
version tag is assigned to master. Then the staging branch is
deleted, and not re-created until the next pre-release cycle. The
development branch is usually sync'd up with the master branch at this
point as well, although what that means is mainly that there's nothing
on master that is missing from development. Unless there's some large
unfinished project under way, it typically means the development
branch is made the same as the current master, because anything else
can be restored from the proposed change branches.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Plan for the 5.9 branch
2020-02-18 19:40 ` dana
2020-02-18 20:44 ` Bart Schaefer
@ 2020-02-19 10:23 ` Daniel Shahaf
2020-02-19 10:32 ` Daniel Shahaf
2 siblings, 0 replies; 11+ messages in thread
From: Daniel Shahaf @ 2020-02-19 10:23 UTC (permalink / raw)
To: dana; +Cc: Zsh hackers list
dana wrote on Tue, 18 Feb 2020 13:40 -0600:
> On 17 Feb 2020, at 03:19, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > I think even before documenting the process, we'll have to agree on
> > what the goal is and what the additional releases would contain. Just bugfixes,
> > or also new features?
>
> Right. All i'm really worried about personally are fixes for security issues
> and the type of regressions we normally correct in .1 releases.
For this sort of thing I think we have two options:
1. Release 5.8.1 from master, including the several small changes that
have already been pushed.
2. Create a new branch off the 5.8 tag, fix the security issue or
regression on that branch, and release _that_ as 5.8.1.
> Beyond that, maybe stuff like trivial completion updates could go in if we're
> planning a patch release anyway — that's what we've done lately with .1
> releases — but i don't think it's important and i'm not suggesting that we go
> out of our way for them.
*nod*
> On 17 Feb 2020, at 03:19, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > What degree of support/compatibility promises will they
> > come with — comparable to a -dev/-test release or to a regular release? Etc.
>
> Re: compatibility, as a rule i would suggest that patch releases under this
> system should not contain anything that Debian/Ubuntu wouldn't be comfortable
> pulling into one of their (non-rolling) releases. Maybe that's slightly too
> strict in practice, but i think that's a reasonable goal at least.
>
Let's try to reach a self-contained definition. How about the
following blacklist rule: backported changes shouldn't be destabilizing
or invasive and shouldn't introduce new APIs? Or a whitelist rule:
changes should fix a bug or add a small/localized feature, while also
meeting the aforementioned (blacklist) criteria?
> Re: support, i'm not sure i even know what promises we make for stable
> releases now, lol
>
> dana
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Plan for the 5.9 branch
2020-02-18 19:40 ` dana
2020-02-18 20:44 ` Bart Schaefer
2020-02-19 10:23 ` Daniel Shahaf
@ 2020-02-19 10:32 ` Daniel Shahaf
2020-02-19 15:21 ` Bart Schaefer
2 siblings, 1 reply; 11+ messages in thread
From: Daniel Shahaf @ 2020-02-19 10:32 UTC (permalink / raw)
To: dana; +Cc: Zsh hackers list
dana wrote on Tue, 18 Feb 2020 13:40 -0600:
> On 17 Feb 2020, at 03:19, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> On 17 Feb 2020, at 03:19, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > What degree of support/compatibility promises will they
> > come with — comparable to a -dev/-test release or to a regular release? Etc.
>
> Re: compatibility, as a rule i would suggest that patch releases under this
> system should not contain anything that Debian/Ubuntu wouldn't be comfortable
> pulling into one of their (non-rolling) releases. Maybe that's slightly too
> strict in practice, but i think that's a reasonable goal at least.
>
> Re: support, i'm not sure i even know what promises we make for stable
> releases now, lol
For one, we implicitly promise compatibility: if something works
in 5.8, users are allowed to assume it will work in 5.9 as well.
(Which by extension means bugs in it will be considered release
blockers)
Now, suppose we add a new feature in March, then in April make
a release off master that ships that feature, and then in May we find
a bug in that feature. Are we allowed to break compatibility with the
the April version of the feature in order to fix the bug?
If the feature hadn't appeared in a release, the answer would be an
unequivocal "Yes". Given that it has appeared in a release, do we promise
to users of that release that we won't break compatibility with what
they have? If we don't promise that, fewer users will install the
additional releases; but if we do make that promise, we'll have less
time to find bugs in features before we're committed to support those
features going forward.
Cheers,
Daniel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Plan for the 5.9 branch
2020-02-19 10:32 ` Daniel Shahaf
@ 2020-02-19 15:21 ` Bart Schaefer
2020-02-19 20:00 ` dana
0 siblings, 1 reply; 11+ messages in thread
From: Bart Schaefer @ 2020-02-19 15:21 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: dana, Zsh hackers list
On Wed, Feb 19, 2020 at 2:32 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Now, suppose we add a new feature in March, then in April make
> a release off master that ships that feature, and then in May we find
> a bug in that feature. Are we allowed to break compatibility with the
> the April version of the feature in order to fix the bug?
If it's a bug such that the feature does not function usably in some
circumstances, or causes a crash, compatibility isn't an issue.
If it's a behavioral difference where the feature does something
usable/useful but inconsistent with the intended behavior, then the
compatibility question arises. The longer the feature has been "in
the wild" the more likely we are to need to keep compatibility. For
two months I wouldn't be especially concerned; two years and it
becomes serious.
I can't think of a better approach than to poll a few user channels
(zsh-users, /r/zsh, whatever) to get a feel for how many people are
depending on the anomalous behavior and whether the repair would be
preferable. Other considerations are how easy it is to make a
run-time decision about which behavior is present (testing a version
number is not an "easy" test in this situation).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Plan for the 5.9 branch
2020-02-19 15:21 ` Bart Schaefer
@ 2020-02-19 20:00 ` dana
0 siblings, 0 replies; 11+ messages in thread
From: dana @ 2020-02-19 20:00 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Daniel Shahaf, Zsh hackers list
On 18 Feb 2020, at 14:44, Bart Schaefer <schaefer@brasslantern.com> wrote:
> Each proposed change goes on its own branch created from master. This
> is rebased on master if necessary before merging with other changes.
We do this part where i work as well. The topic-branch thing seems to be most
beneficial when you're using those branches for QA, or when you're using
something like GitLab for reviews and/or MRs; in a system like this where we
just e-mail patches around anyway, i guess it doesn't make a huge difference
outside of each dev's personal work-flow
On 19 Feb 2020, at 04:23, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> 1. Release 5.8.1 from master, including the several small changes that
> have already been pushed.
Which is what we've been doing, and it's fine, as long as master hasn't moved
on, or it's not preventing it from doing so. I'm definitely not concerned if a
few documentation/test/completion improvements make it into a .1
On 19 Feb 2020, at 04:23, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Let's try to reach a self-contained definition. How about the
> following blacklist rule: backported changes shouldn't be destabilizing
> or invasive and shouldn't introduce new APIs? Or a whitelist rule:
> changes should fix a bug or add a small/localized feature, while also
> meeting the aforementioned (blacklist) criteria?
Both of those seem unobjectionable to me
On 19 Feb 2020, at 04:32, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Now, suppose we add a new feature in March, then in April make
> a release off master that ships that feature, and then in May we find
> a bug in that feature. Are we allowed to break compatibility with the
> the April version of the feature in order to fix the bug?
Are the considerations in this scenario any different from how it is now?
Maybe i'm not following. Either way, in general, i agree with what Bart said
dana
^ permalink raw reply [flat|nested] 11+ messages in thread