zsh-workers
 help / color / Atom feed
* Plan for the 5.9 branch
@ 2020-02-16 11:15 Daniel Shahaf
  2020-02-16 14:52 ` Peter Stephenson
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Daniel Shahaf @ 2020-02-16 11:15 UTC (permalink / raw)
  To: zsh-workers

A few weeks ago I created a 5.9 branch for bugfixes/patches that seemed
too risky to push to master during pre-release stabilization.

I'd like to merge that branch to master in a few weeks, when it's clear
there won't be a 5.8.1 for regressions.

(Alternatively, we could merge the branch now; that won't block us from
creating a 5.8.1 regression-fixing release with or without the changes
from the 5.9 branch.)

---

As to branching policy, in the future we should probably do things the
other way around; that is: in the run-up to the 5.9 release next year,
rather than stabilize on master and open a 5.10 branch for destabilizing
changes, we should open a 5.9 branch for stabilization and leave master
open to destabilizing changes.

(Fortunately, due to how git fast-forward merges work, the current 5.9
branch won't interfere with this plan.)

Makes sense?

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Plan for the 5.9 branch
  2020-02-16 11:15 Plan for the 5.9 branch Daniel Shahaf
@ 2020-02-16 14:52 ` Peter Stephenson
  2020-02-17  2:47 ` dana
  2020-03-07 22:07 ` Daniel Shahaf
  2 siblings, 0 replies; 11+ messages in thread
From: Peter Stephenson @ 2020-02-16 14:52 UTC (permalink / raw)
  To: zsh-workers

On Sun, 2020-02-16 at 11:15 +0000, Daniel Shahaf wrote:
> A few weeks ago I created a 5.9 branch for bugfixes/patches that seemed
> too risky to push to master during pre-release stabilization.
> 
> I'd like to merge that branch to master in a few weeks, when it's clear
> there won't be a 5.8.1 for regressions.
> 
> (Alternatively, we could merge the branch now; that won't block us from
> creating a 5.8.1 regression-fixing release with or without the changes
> from the 5.9 branch.)

We can probably wait the odd week to see if there's any sorting
out, but there doesn't seem to be any point hanging on too long.

> As to branching policy, in the future we should probably do things the
> other way around; that is: in the run-up to the 5.9 release next year,
> rather than stabilize on master and open a 5.10 branch for destabilizing
> changes, we should open a 5.9 branch for stabilization and leave master
> open to destabilizing changes.
> 
> (Fortunately, due to how git fast-forward merges work, the current 5.9
> branch won't interfere with this plan.)

That would be more standard.

The counter argument is that anyone tracking the shell is most likely to
stick with the master branch, so that's the one that gets the most
testing.  However, as long as all changes are on the master branch we
should see any issues with the release anyway.

pws


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Plan for the 5.9 branch
  2020-02-16 11:15 Plan for the 5.9 branch Daniel Shahaf
  2020-02-16 14:52 ` Peter Stephenson
@ 2020-02-17  2:47 ` dana
  2020-02-17  9:19   ` Daniel Shahaf
  2020-03-07 22:07 ` Daniel Shahaf
  2 siblings, 1 reply; 11+ messages in thread
From: dana @ 2020-02-17  2:47 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

On 16 Feb 2020, at 05:15, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> As to branching policy, in the future we should probably do things the
> other way around; that is: in the run-up to the 5.9 release next year,
> rather than stabilize on master and open a 5.10 branch for destabilizing
> changes, we should open a 5.9 branch for stabilization and leave master
> open to destabilizing changes.

I like this. When we reach 'feature freeze' for 5.9, we branch off, only
back-port important stuff from master, and then release 5.9 based on that
branch. If we find any regressions or security bugs, we can back-port those
fixes and release 5.9.1 or whatever.

Oliver pointed out before that nothing stops us from back-porting stuff and
releasing patch versions now, but i think the important thing is to have a
standardised process for it. It makes the releases go smoothly, and it helps
everyone make sense of the repo and the version history. And obv we'd document
the process somewhere for anyone who might get confused.

The main concern i've heard about it in the past is that maybe some of the
devs don't have the bandwidth for the extra work, but ideally the back-ports
would be infrequent, and presumably it'd fall on the RM to make sure nothing
falls through the cracks

dana


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Plan for the 5.9 branch
  2020-02-17  2:47 ` dana
@ 2020-02-17  9:19   ` Daniel Shahaf
  2020-02-18 19:40     ` dana
  0 siblings, 1 reply; 11+ messages in thread
From: Daniel Shahaf @ 2020-02-17  9:19 UTC (permalink / raw)
  To: Zsh hackers list

dana wrote on Sun, 16 Feb 2020 20:47 -0600:
> On 16 Feb 2020, at 05:15, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > As to branching policy, in the future we should probably do things the
> > other way around; that is: in the run-up to the 5.9 release next year,
> > rather than stabilize on master and open a 5.10 branch for destabilizing
> > changes, we should open a 5.9 branch for stabilization and leave master
> > open to destabilizing changes.  
> 
> I like this. When we reach 'feature freeze' for 5.9, we branch off, only
> back-port important stuff from master, and then release 5.9 based on that
> branch. If we find any regressions or security bugs, we can back-port those
> fixes and release 5.9.1 or whatever.

Yes.

(When physically doing the commits to the two branches, I'm not sure if it'll be
easier to cherry-pick, or to commit to the 5.9 branch first and then to run
«git merge 5.9» in master.)

> Oliver pointed out before that nothing stops us from back-porting stuff and
> releasing patch versions now,

Indeed, there's nothing stopping us from creating a 5.8 branch right now, if
people are willing to maintain it.

> but i think the important thing is to have a
> standardised process for it. It makes the releases go smoothly, and it helps
> everyone make sense of the repo and the version history. And obv we'd document
> the process somewhere for anyone who might get confused.

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?  What degree of support/compatibility promises will they
come with — comparable to a -dev/-test release or to a regular release?  Etc.

> The main concern i've heard about it in the past is that maybe some of the
> devs don't have the bandwidth for the extra work, but ideally the back-ports
> would be infrequent, and presumably it'd fall on the RM to make sure nothing
> falls through the cracks
> 
> dana
> 


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Plan for the 5.9 branch
  2020-02-17  9:19   ` Daniel Shahaf
@ 2020-02-18 19:40     ` dana
  2020-02-18 20:44       ` Bart Schaefer
                         ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: dana @ 2020-02-18 19:40 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

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.

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.

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

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

* Re: Plan for the 5.9 branch
  2020-02-16 11:15 Plan for the 5.9 branch Daniel Shahaf
  2020-02-16 14:52 ` Peter Stephenson
  2020-02-17  2:47 ` dana
@ 2020-03-07 22:07 ` Daniel Shahaf
  2 siblings, 0 replies; 11+ messages in thread
From: Daniel Shahaf @ 2020-03-07 22:07 UTC (permalink / raw)
  To: zsh-workers

Daniel Shahaf wrote on Sun, 16 Feb 2020 11:15 +0000:
> A few weeks ago I created a 5.9 branch for bugfixes/patches that seemed
> too risky to push to master during pre-release stabilization.
> 
> I'd like to merge that branch to master in a few weeks, when it's clear
> there won't be a 5.8.1 for regressions.

Okay.  I've merged master into 5.9, pushed that, and then merged 5.9 into
master by running «git checkout master && git merge --no-ff origin/5.9».

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, back to index

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-16 11:15 Plan for the 5.9 branch Daniel Shahaf
2020-02-16 14:52 ` Peter Stephenson
2020-02-17  2:47 ` dana
2020-02-17  9:19   ` Daniel Shahaf
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
2020-02-19 20:00           ` dana
2020-03-07 22:07 ` Daniel Shahaf

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git