Re: Rejiggering the branches

[Robert Goldman]

On 14 Jul 2021, at 16:58, Raymond Toy wrote:

If there are tags (or branches) to indicate when the release is done, 
then a stable branch is ok with me.  I just want a way to get to a 
release somehow.  (Not that I've had to debug an issue in asdf.  But 
if I did, I want to be able to extract various releases for 
testing.) 


Quick response:  there is always a current `release` branch.  In 
addition, each release is tagged with its version number, so at any time 
one can recover any previous release.


Cheers,
R

Re: Rejiggering the branches

[Robert Goldman]

On 13 Jul 2021, at 10:20, Eric Timmons wrote:


Attila Lendvai  writes:

what i would do:

   - one branch that holds the bleeding edge. i'd call it main, just 
to go

   with the flow.
   - branches for ASDF versions (down to the desired resolution, 
probably
   major.minor), so that you can easily cherry pick or backport fixes 
into
   them. a new version-branch is forked off of main whenever a 
release happens.
   - optionally a stable *tag* as an indirection to the latest 
release. it

   communicates which specific git revision is it that the maintainer
   considers the stable state at any moment in time. it comes handy 
e.g. in CI

   scripts that want to check out the latest ASDF release, etc...



I like this!

IMO a big win of having the major and minor number in the branch name 
is
that it's a better experience for users. If it's a single 
`maintenance`
branch then a git pull may wind up changing their version completely. 
If

they have any local changes as well, things might get a bit hairy when
`maintenance` changes minor versions as that wouldn't be a 
fast-forward

update.


I guess I'm surprised you say this.  I don't *ever* want us to have more 
than a single live maintenance branch.  I absolutely *never* want to 
support more than a single `main` version and a single `stable` version.


So, to me, it's a *feature* that if you git pull maintenance and you 
find out that what you are maintaining has changed.  And to me it seems 
like a *bad* user experience if I can end up wasting my time interacting 
with a branch that is obsolete and of no further interest.  I'd rather 
know that things have changed -- and I would expect to do `git pull 
--ff-only` on `stable`.


I am surprised that so many people want to have a branch like `v3.3`. 
This adds a memory burden that `stable` doesn't have, in the same way 
that Raymond pointed out that having `dev` adds a memory burden beyond 
using the standard `main` or `master`.  Honestly, I find it hard to 
remember whether 3.3 or 3.4 is the current released version!


I'm curious -- how many of the people who want `v3.3` instead of 
`stable` expect that they would actually interact with this branch, 
checking it out and supplying merge requests, versus just thinking it's 
better in some ideal fashion?

Re: Rejiggering the branches

[Attila Lendvai]

>
> Nah, a tag is supposed to never change. The mechanism for a "tag that
> changes" is called... a branch.


the user story that i desire is a label that someone with the commit bit
can move around freely, and then it gets automatically synchronized to
everyone else who pulls/fetches the repo (i.e. *without* reading multiple
blog posts and issuing multiple git commands).

a release branch, especially with force-pushed commits, is rather far from
that in terms of the user experience. but then maybe i should learn to love
merge commits...

now, how exactly git behaves is another story. it never seizes to surprise
me.

(i'm fine with calling the "stable" label as "release", or whatever else.
the actual name wasn't my point.)

- attila

Re: Rejiggering the branches

[Eric Timmons]

Attila Lendvai  writes:
> what i would do:
>
>- one branch that holds the bleeding edge. i'd call it main, just to go
>with the flow.
>- branches for ASDF versions (down to the desired resolution, probably
>major.minor), so that you can easily cherry pick or backport fixes into
>them. a new version-branch is forked off of main whenever a release 
> happens.
>- optionally a stable *tag* as an indirection to the latest release. it
>communicates which specific git revision is it that the maintainer
>considers the stable state at any moment in time. it comes handy e.g. in CI
>scripts that want to check out the latest ASDF release, etc...
>

I like this!

IMO a big win of having the major and minor number in the branch name is
that it's a better experience for users. If it's a single `maintenance`
branch then a git pull may wind up changing their version completely. If
they have any local changes as well, things might get a bit hairy when
`maintenance` changes minor versions as that wouldn't be a fast-forward
update.

Additionally having a version independent `stable` identifier (tag or
branch) is nice for the use cases described here.

-Eric

Re: Rejiggering the branches

[Faré]

On Tue, Jul 13, 2021 at 9:34 AM Attila Lendvai  wrote:
>>
>>
>> Would the "stable" branch be any different from the "release" branch?
>> If it's actually a not-so-stable development branch for 3.3 while a
>> separate branch contains development for 3.4, then maybe indeed
>> calling branches v3.3 and v3.4 make more sense.
>>
>
> +1
>
> what i would do:
>
> one branch that holds the bleeding edge. i'd call it main, just to go with 
> the flow.
> branches for ASDF versions (down to the desired resolution, probably 
> major.minor), so that you can easily cherry pick or backport fixes into them. 
> a new version-branch is forked off of main whenever a release happens.
> optionally a stable *tag* as an indirection to the latest release. it 
> communicates which specific git revision is it that the maintainer considers 
> the stable state at any moment in time. it comes handy e.g. in CI scripts 
> that want to check out the latest ASDF release, etc...
>
> note though that this last point requires force-pushing the stable tag, which 
> i have done before, but i'm not completely sure it results in a slick 
> workflow. the main question is whether or not a git fetch/pull silently and 
> automatically updates the tag in the local repo.
>
Nah, a tag is supposed to never change. The mechanism for a "tag that
changes" is called... a branch. And that's precisely why we have a
release branch. And yes, if we have version-based branches v1, v2,
v3.0, v3.1, v3.2, v3.3, v3.4... then it makes sense to force-push to
the release branch when the release "jumps" from v3.3 to v3.4... or to
"merge" the latest release into master or main before to make a new
release off of it so there is no need for force.

—♯ƒ • François-René Rideau • Co-Founder and CEO, MuKn.io
Love thy neighbor as thyself, but choose your neighborhood.
— Louise Beal

Re: Rejiggering the branches

[Attila Lendvai]

>
>
> Would the "stable" branch be any different from the "release" branch?
> If it's actually a not-so-stable development branch for 3.3 while a
> separate branch contains development for 3.4, then maybe indeed
> calling branches v3.3 and v3.4 make more sense.
>
>
+1

what i would do:

   - one branch that holds the bleeding edge. i'd call it main, just to go
   with the flow.
   - branches for ASDF versions (down to the desired resolution, probably
   major.minor), so that you can easily cherry pick or backport fixes into
   them. a new version-branch is forked off of main whenever a release happens.
   - optionally a stable *tag* as an indirection to the latest release. it
   communicates which specific git revision is it that the maintainer
   considers the stable state at any moment in time. it comes handy e.g. in CI
   scripts that want to check out the latest ASDF release, etc...

note though that this last point requires force-pushing the stable tag,
which i have done before, but i'm not completely sure it results in a slick
workflow. the main question is whether or not a git fetch/pull silently and
automatically updates the tag in the local repo.

- attila

Re: Rejiggering the branches

[phoebe Goldman]

> Just like Debian has stable and testing, but the precise meaning of these 
> changes over time.
> 
If your intention is to do the same thing as Debian, why not use the same 
names, too?


> On Jul 12, 2021, at 2:56 PM, Robert Goldman  wrote:
> 
> On 12 Jul 2021, at 13:36, Faré wrote:
> 
> Would the "stable" branch be any different from the "release" branch?
> If it's actually a not-so-stable development branch for 3.3 while a
> separate branch contains development for 3.4, then maybe indeed
> calling branches v3.3 and v3.4 make more sense.
> 
> Yes, it would, because this branch would be where we put fixes to the 
> released branch while, on main, we develop code for 3.4.
> 
> I was thinking of not calling the branch v3.3 because if we ever get past 
> 3.4, we would want a maintenance branch for 3.4, while main would be for 3.5 
> or 4 depending on what the future holds.
> 
> I have a mild preference for having the maintenance branch, whatever we call 
> it, just point to whatever has been released and is accumulating bug fixes. I 
> figured that having a stable would be like having a main, instead of renaming 
> main to whatever the upcoming version number is. Just like Debian has stable 
> and testing, but the precise meaning of these changes over time.
> 
> I'm willing to be argued out of this, as I was argued out of dev in favor of 
> main, but I am not convinced by the arguments for v3.3 versus stable yet. 
> What makes us need v3.3 instead of stable if we don't need v3.4 instead of 
> main?
> 
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• 
> http://fare.tunes.org 
> The knowable universe is everything, as far as we can know.
> 
> On Mon, Jul 12, 2021 at 2:13 PM Martin Simmons mar...@lispworks.com 
>  wrote:
> 
> On Mon, 12 Jul 2021 19:52:01 +0200, Rudolf Schlatte said:
> 
> Cancel-Lock: sha1:dqYu7Py9JNAyZJWALyW1kLx3PD8=
> 
> "Robert Goldman" rpgold...@sift.info 
> writes:
> 
> If stable seems bad, is there another name we could use to avoid renaming? 
> Like maint for "maintenance"?
> 
> I don't love maint, because it's too close to main, and it seems like main 
> has an edge in familiarity if not in meaningfulness.
> 
> legacy?
> 
> Unless we can come up with something better than stable, it seems like the 
> least-worst alternative. But there's all week to come up with something 
> better!
> 
> In the first email you said that the purpose of that branch was to
> permit continuation of the 3.3 release series, so maybe call the branch
> "v3.3"? That way, there can be multiple such branches without resorting
> to "stable", "oldstable" etc. names.
> 
> Yes, that's the kind of name I meant.
> 
> Or include the stableness in the name with something like "stable/3.3"
> (c.f. FreeBSD).
> 
> --
> Martin Simmons
> LispWorks Ltd
> http://www.lispworks.com/ 


signature.asc
Description: Message signed with OpenPGP

Re: Rejiggering the branches

[Robert Goldman]

On 12 Jul 2021, at 13:36, Faré wrote:


Would the "stable" branch be any different from the "release" branch?
If it's actually a not-so-stable development branch for 3.3 while a
separate branch contains development for 3.4, then maybe indeed
calling branches v3.3 and v3.4 make more sense.


Yes, it would, because this branch would be where we put fixes to the 
released branch while, on `main`, we develop code for 3.4.


I was thinking of not calling the branch `v3.3` because if we ever get 
past 3.4, we would want a maintenance branch for 3.4, while `main` would 
be for 3.5 or 4 depending on what the future holds.


I have a mild preference for having the maintenance branch, whatever we 
call it, just point to whatever has been released and is accumulating 
bug fixes.  I figured that having a `stable` would be like having a 
`main`, instead of renaming `main` to whatever the upcoming version 
number is.  Just like Debian has `stable` and `testing`, but the precise 
meaning of these changes over time.


I'm willing to be argued out of this, as I was argued out of `dev` in 
favor of `main`, but I am not convinced by the arguments for `v3.3` 
versus `stable` yet.  What makes us need `v3.3` instead of stable if we 
don't need `v3.4` instead of `main`?


—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• 
http://fare.tunes.org

The knowable universe is everything, as far as we can know.

On Mon, Jul 12, 2021 at 2:13 PM Martin Simmons  
wrote:



On Mon, 12 Jul 2021 19:52:01 +0200, Rudolf Schlatte said:

Cancel-Lock: sha1:dqYu7Py9JNAyZJWALyW1kLx3PD8=

"Robert Goldman" 
writes:

If stable seems bad, is there another name we could use to avoid 
renaming? Like maint for "maintenance"?


I don't love maint, because it's too close to main, and it seems 
like main has an edge in familiarity if not in meaningfulness.


legacy?

Unless we can come up with something better than stable, it seems 
like the least-worst alternative. But there's all week to come up 
with something better!




In the first email you said that the purpose of that branch was to
permit continuation of the 3.3 release series, so maybe call the 
branch
"v3.3"?  That way, there can be multiple such branches without 
resorting

to "stable", "oldstable" etc. names.


Yes, that's the kind of name I meant.

Or include the stableness in the name with something like 
"stable/3.3"

(c.f. FreeBSD).

--
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/

Re: Rejiggering the branches

[Faré]

Would the "stable" branch be any different from the "release" branch?
If it's actually a not-so-stable development branch for 3.3 while a
separate branch contains development for 3.4, then maybe indeed
calling branches v3.3 and v3.4 make more sense.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The knowable universe is everything, as far as we can know.

On Mon, Jul 12, 2021 at 2:13 PM Martin Simmons  wrote:
>
> > On Mon, 12 Jul 2021 19:52:01 +0200, Rudolf Schlatte said:
> > Cancel-Lock: sha1:dqYu7Py9JNAyZJWALyW1kLx3PD8=
> >
> > "Robert Goldman" 
> > writes:
> >
> > > If stable seems bad, is there another name we could use to avoid 
> > > renaming? Like maint for "maintenance"?
> > >
> > > I don't love maint, because it's too close to main, and it seems like 
> > > main has an edge in familiarity if not in meaningfulness.
> > >
> > > legacy?
> > >
> > > Unless we can come up with something better than stable, it seems like 
> > > the least-worst alternative. But there's all week to come up with 
> > > something better!
> > >
> >
> > In the first email you said that the purpose of that branch was to
> > permit continuation of the 3.3 release series, so maybe call the branch
> > "v3.3"?  That way, there can be multiple such branches without resorting
> > to "stable", "oldstable" etc. names.
>
> Yes, that's the kind of name I meant.
>
> Or include the stableness in the name with something like "stable/3.3"
> (c.f. FreeBSD).
>
> --
> Martin Simmons
> LispWorks Ltd
> http://www.lispworks.com/
>

Re: Rejiggering the branches

[Robert Dodier]

On Mon, Jul 12, 2021 at 10:52 AM Rudolf Schlatte  wrote:

> In the first email you said that the purpose of that branch was to
> permit continuation of the 3.3 release series, so maybe call the branch
> "v3.3"?  That way, there can be multiple such branches without resorting
> to "stable", "oldstable" etc. names.

Hi everyone, I am only an interested onlooker, but anyway I would like
to second the motion for a branch named according to the version
series. Specifically I'll suggest version-3_3 (I seem to recall Git
forbids "." in branch names) with the understanding that every version
on that branch will be 3.3.something.

In this picture development continues on a branch named master or main
or dev or whatever.

Commits can be cherry picked from the, um, primary development branch
to the release branch to backport any changes deemed appropriate.

Any future releases would be on a new branch, presumably version-3_4
or version-4 or whatever; the version-3_3 branch would not be reused
for that purpose.

The benefit of such a scheme, I believe, is just to make it clearer
what's what.

FWIW

Robert Dodier

Re: Rejiggering the branches

[Martin Simmons]

> On Mon, 12 Jul 2021 19:52:01 +0200, Rudolf Schlatte said:
> Cancel-Lock: sha1:dqYu7Py9JNAyZJWALyW1kLx3PD8=
> 
> "Robert Goldman" 
> writes:
> 
> > If stable seems bad, is there another name we could use to avoid renaming? 
> > Like maint for "maintenance"?
> >
> > I don't love maint, because it's too close to main, and it seems like main 
> > has an edge in familiarity if not in meaningfulness.
> >
> > legacy?
> >
> > Unless we can come up with something better than stable, it seems like the 
> > least-worst alternative. But there's all week to come up with something 
> > better!
> >
> 
> In the first email you said that the purpose of that branch was to
> permit continuation of the 3.3 release series, so maybe call the branch
> "v3.3"?  That way, there can be multiple such branches without resorting
> to "stable", "oldstable" etc. names.

Yes, that's the kind of name I meant.

Or include the stableness in the name with something like "stable/3.3"
(c.f. FreeBSD).

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/

Re: Rejiggering the branches

[Rudolf Schlatte]

"Robert Goldman" 
writes:

> If stable seems bad, is there another name we could use to avoid renaming? 
> Like maint for "maintenance"?
>
> I don't love maint, because it's too close to main, and it seems like main 
> has an edge in familiarity if not in meaningfulness.
>
> legacy?
>
> Unless we can come up with something better than stable, it seems like the 
> least-worst alternative. But there's all week to come up with something 
> better!
>

In the first email you said that the purpose of that branch was to
permit continuation of the 3.3 release series, so maybe call the branch
"v3.3"?  That way, there can be multiple such branches without resorting
to "stable", "oldstable" etc. names.

Rudi

Re: Rejiggering the branches

[Robert Goldman]

If `stable` seems bad, is there another name we could use to avoid 
renaming?  Like `maint` for "maintenance"?


I don't love `maint`, because it's too close to `main`, and it seems 
like `main` has an edge in familiarity if not in meaningfulness.


`legacy`?

Unless we can come up with something better than `stable`, it seems like 
the least-worst alternative.  But there's all week to come up with 
something better!


Cheers,
R


On 12 Jul 2021, at 11:13, Martin Simmons wrote:


On Mon, 12 Jul 2021 08:59:16 -0500, Robert Goldman said:


As we move forward, and try to add some new facilities to ASDF, this
seems like a good time to revise the branching structure that we use.

In particular, I would like to add a `stable` branch that will permit
continuation of the 3.3 release series, the need for which is
illustrated by Mark E's recent merge request.


OK, but once you name something "stable", can you change it very much? 
 What
happens when the development branch contains something that is stable 
enough
to call stable again?  If you intend this branch to be the 3.3 release 
series

then using numbers in the name might be preferable.


If we are going to make that change, it seems like a good time to 
rename

the `master` branch to either `main` or `dev`.  Any preferences?


I suggest calling it main like many other projects, unless you intend 
to do
all development on a non-default branch and use main for something 
else.

Using the same name as other projects makes it easier to find it.

--
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/

Re: Rejiggering the branches

[Martin Simmons]

> On Mon, 12 Jul 2021 08:59:16 -0500, Robert Goldman said:
> 
> As we move forward, and try to add some new facilities to ASDF, this 
> seems like a good time to revise the branching structure that we use.
> 
> In particular, I would like to add a `stable` branch that will permit 
> continuation of the 3.3 release series, the need for which is 
> illustrated by Mark E's recent merge request.

OK, but once you name something "stable", can you change it very much?  What
happens when the development branch contains something that is stable enough
to call stable again?  If you intend this branch to be the 3.3 release series
then using numbers in the name might be preferable.


> If we are going to make that change, it seems like a good time to rename 
> the `master` branch to either `main` or `dev`.  Any preferences?

I suggest calling it main like many other projects, unless you intend to do
all development on a non-default branch and use main for something else.
Using the same name as other projects makes it easier to find it.

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/

Re: Rejiggering the branches

[Raymond Toy]

I'd prefer main over dev.  Mostly because github has (forcibly) renamed
master to main (along with other projects) so I'm used to main being what
master used to be.

Having to remember master, main, and dev is just too much work for my old
brain.

On Mon, Jul 12, 2021 at 7:34 AM Robert Goldman  wrote:

> As we move forward, and try to add some new facilities to ASDF, this seems
> like a good time to revise the branching structure that we use.
>
> In particular, I would like to add a stable branch that will permit
> continuation of the 3.3 release series, the need for which is illustrated
> by Mark E's recent merge request.
>
> If we are going to make that change, it seems like a good time to rename
> the master branch to either main or dev. Any preferences?
>
> I'd like to have a quick discussion about this over the week, with an eye
> to getting a solution in place by Friday.
>
> Thanks for your thoughts,
>
> R
>


-- 
Ray

Re: Rejiggering the branches

[Phoebe Goldman]

I prefer dev over main, since it’s more clear about the purpose of the branch. 
Main is just not a very descriptive word. For one thing, for most people, 
stable will actually be the “main” branch.

This isn’t a strong preference, but honestly I doubt anyone has that strong of 
feelings on the subject.

best,
phoebe

> On Jul 12, 2021, at 9:59 AM, Robert Goldman  wrote:
> 
> As we move forward, and try to add some new facilities to ASDF, this seems 
> like a good time to revise the branching structure that we use.
> 
> In particular, I would like to add a stable branch that will permit 
> continuation of the 3.3 release series, the need for which is illustrated by 
> Mark E's recent merge request.
> 
> If we are going to make that change, it seems like a good time to rename the 
> master branch to either main or dev. Any preferences?
> 
> I'd like to have a quick discussion about this over the week, with an eye to 
> getting a solution in place by Friday.
> 
> Thanks for your thoughts,
> 
> R
> 



signature.asc
Description: Message signed with OpenPGP