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
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 rpgoldman@sift.info 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
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 rpgoldman@sift.info 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
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.
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/
"Robert Goldman" rpgoldman@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.
Rudi
On Mon, 12 Jul 2021 19:52:01 +0200, Rudolf Schlatte said:
Cancel-Lock: sha1:dqYu7Py9JNAyZJWALyW1kLx3PD8=
"Robert Goldman" rpgoldman@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).
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 martin@lispworks.com wrote:
On Mon, 12 Jul 2021 19:52:01 +0200, Rudolf Schlatte said:
Cancel-Lock: sha1:dqYu7Py9JNAyZJWALyW1kLx3PD8=
"Robert Goldman" rpgoldman@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/
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 martin@lispworks.com wrote:
> On Mon, 12 Jul 2021 19:52:01 +0200, Rudolf Schlatte said:
Cancel-Lock: sha1:dqYu7Py9JNAyZJWALyW1kLx3PD8=
"Robert Goldman" rpgoldman@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/
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 rpgoldman@sift.info 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 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 martin@lispworks.com mailto:martin@lispworks.com wrote:
On Mon, 12 Jul 2021 19:52:01 +0200, Rudolf Schlatte said:
Cancel-Lock: sha1:dqYu7Py9JNAyZJWALyW1kLx3PD8=
"Robert Goldman" rpgoldman@sift.info mailto:rpgoldman@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/ http://www.lispworks.com/
On Mon, Jul 12, 2021 at 12:04 PM Robert Goldman rpgoldman@sift.info wrote:
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.
Well, for what it's worth, I would suggest creating a new branch for each release or release series, not that main or any branch is renamed.
Just like Debian has stable and testing, but the precise meaning of these changes over time.
Well, it is precisely this drifting meaning which, I believe, you are better off avoiding.
best,
Robert Dodier
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
On Tue, Jul 13, 2021 at 9:34 AM Attila Lendvai attila.lendvai@gmail.com 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
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
Attila Lendvai attila.lendvai@gmail.com 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
On Tue, Jul 13, 2021 at 8:20 AM Eric Timmons etimmons@mit.edu wrote:
Attila Lendvai attila.lendvai@gmail.com 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.
For me, a "stable" tag/branch that keeps changing the contents isn't "stable".
My 2 cents. I'm not an asdf dev, and only grab asdf when releases are done (or need to test some new things being introduced.)
-Eric
On 13 Jul 2021, at 10:20, Eric Timmons wrote:
Attila Lendvai attila.lendvai@gmail.com 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?
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?
i think our mental model of version tracking is different.
imagine this scenario (that, IIUYC, you explicitly stated that you don't want to support):
- v4.0 is released, but it contains refactorings that require non-trivial efforts from users and implementations to integrate. - main holds quite a few shady/untested commits that will eventually become v4.1 (by forking off of main at a future point in time, then doing some testing/fixing in the release branch, and then eventually tagging its head as v4.1.0, then repeat and tag v4.1.1, etc). - v3.4 is the latest release in the v3.x line, which most implementations are still shipping with. - along comes a bugfix at this point in time, that you commit into main.
let's assume that you want to support both camps; i.e. the late adopters, by cherry picking the fix from main into the v3.4 branch, and releasing v3.4.n+1. and you also want to support the early adopters by cherry picking the fix into the v4.0 branch from main. if you're lucky line-diff wise, then this is two git cherry-pick's, and firing up the release script twice.
stale branches, that won't ever receive fixes or backports, can be deleted (and from then on rely on the tags to retain the release history of that now finalized branch of the version tree).
from my POV it's a pretty straightforward setup, but i'm not saying that this scenario is something that you should or desire to support, though.
Maybe I'm a bit naive, but what about a setup like:
main - development happens against this as PRs and so on
When you do a release, tag it against this branch.
For the topic of people staying on 3.3 or whatever version they prefer: if such a situation were to actually happen, that they submit a fix that specifically patches a bug in 3.3, you can create a hotfix branch rooted at that tagged version. Meaning, don't create a branch until you need one.
The risk of course is having greatly diverging features added to some older version, but I'd like to hope that after however many decades, ASDF is at least mature enough that something like that wouldn't happen and only hotfixes would be applied to those release branches, if any at all.
Finally, if you truly desire a 'stable' equivalent (releases only), simply move development from 'main' to 'dev', and only fast forward 'main' to 'dev' when a stable release happens.
eg
dev - development branch, changes voa prs, patches, etc
main - stable releases branch. fast forwarded to (or merge-commited) 'dev' when a release occurs.
tag every release. If somebody in the future finds a hotfix in some old version, create a branch at that tag.
But that's just my two cents. Best of luck
On Tue, Jul 13, 2021, 4:35 PM Robert Goldman rpgoldman@sift.info wrote:
On 13 Jul 2021, at 10:20, Eric Timmons wrote:
Attila Lendvai attila.lendvai@gmail.com 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?
On Tue, Jul 13, 2021 at 1:35 PM Robert Goldman rpgoldman@sift.info wrote:
On 13 Jul 2021, at 10:20, Eric Timmons wrote:
Attila Lendvai attila.lendvai@gmail.com 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 think it's easy to tell since the numbers are increasing, so if there's v3.3 and v3.4, then v3.4 is the current released version. If you're working on v3.4, then I would expect things to be on main until you're ready and then a v3.4 branch is made. This keeps getting updated until it's release at which point a tag could be added to indicate the release.
But all of this requires work. And since I'm not the one doing the work, I defer to you for the final decision.
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?
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.)
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
On Mon, Jul 12, 2021 at 10:52 AM Rudolf Schlatte rudi@constantly.at 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
-
Attila Lendvai -
Eric Timmons -
Faré -
Martin Simmons -
Phoebe Goldman -
phoebe Goldman
-
Raymond Toy -
Robert Dodier -
Robert Goldman -
Rudolf Schlatte -
Wilfredo Velazquez