[request] use tags on branch master

[avih]

As it stands, the master branch is currently without tags.

While there are branches for betas and 1.0, it's hard to tell from the master history where the branches were split from master.

I don't know what the release policy is, but if it's not possible/intended to have the actual tags on master (e.g. 1.0-beta-2), then it should still be possible to tag master with something like pre-1.0-beta-2 for the commit from which beta 2 was branched. I think it could also be done retroactively.

I think this would allow easier tracking of changes between releases on the actual commits history (compared to manually curated list which is currently attached to the beta branch).

[McDutchie]

The 1.0 branch split from master just once, at 246062f. It's technically been independent ever since. I've been cherry-picking most changes from master into it. Meaning, beta 2 was not branched from any master commit – it's just a commit in the 1.0 branch.

So, for the moment, what you suggest is not possible. It may become possible if I choose a different branching policy starting from the 1.1 release series. So far, the release policy has been "Martijn is making it up as he goes along", so I'm open to further discussion.

I will note that anything that requires a lot of forward planning and strict scheduling would need someone other than me to be in charge of it, because I'm hopeless at that.

I was planning to be more adventurous with the master branch and commit things there that are not yet ready for beta testing. That hasn't quite been happening yet, but I've got a few things in the pipeline that I may get to soonish, now that beta 2 is out.

[avih]

The 1.0 branch split from master just once, at 246062f. It's technically been independent ever since. I've been cherry-picking most changes from master into it

Thanks for the explanation.

Indeed, the 1.0 branch does allow explicit lookup of tags and the commits between them.

In this case, what's the significance of the current master branch? I.e. which kinds of commits don't currently make it to the 1.0 branch?

And if indeed most commits make it to the 1.0 branch, maybe it would be easier to restructure it in some way so that most commits don't need to be picked, and instead only those which won't make it be committed to some other branch? (sorry, I don't grasp the past-1.0 development progression/model clearly).

EDIT: huh, replying to your comment seems to make it a non-linear thread. I didn't intend that...

[McDutchie]

What I could do instead is the following:

1. Make 1.0 the default branch that users see when they visit the main github page. At this point, that makes more sense anyway. We're starting to be in OS distributions and they're taking the betas as release versions for lack of anything better. Each time we move to a new release branch (1.1, 2.0, etc.) that one is set as the default.
2. Rename the master branch to dev, just for clarity -- this is where development happens, it's not necessarily what releases are based off.

@JohnoKing, @hyenias, what do you think?

[hyenias]

I am new to the world of git. From my exceedingly entry level view of it all, I thought what you were doing currently is something similar to https://unixsheikh.com/tutorials/a-simple-git-workflow-using-main-as-the-development-branch.html. Probably need to rename master to main. See how https://github.com/python/cpython does it. All-in-all, github is for developers and I would not recommend forcing developers to always hunt down the correct development branch. Users are typically not going to go reading repo's code. What could be done to assist users is perhaps a link to a wiki page up front and center that could direct them to the correct steps to download and compile for those power users for the various releases/tags/etc. Given more time and resources, a github.io web page could be created superseding the wiki. But web content takes time... So that is down the road.

Package managers that create prebuilt binaries or grab a release for ksh have skills so I believe the above mentioned examples probably would satisfy them.

Cheers,
hyenias

[JohnoKing]

All-in-all, github is for developers and I would not recommend forcing developers to always hunt down the correct development branch.

I agree with what @hyenias said, especially this statement. IMO the development branch shouldn't be hidden from view. That said I wouldn't be opposed to renaming the development branch to something else signifying its purpose (e.g., renaming master to dev). Package mantainers should be obtaining ksh from the relevant git tags (i.e., the releases on the Releases page). Perhaps the README could be updated to point package maintainers to the git tags and/or the releases page.