KStars v3.5.0 Release Date?

[Eric Dejouhanet]

Hello,

Let me just comment on your four points. My proposal is not to change
the way we use branches:

> 1. Master should reflect the latest bleeding-edge code. It should be *buildable* and *usable*, but it should not be expected to be stable and thoroughly tested.

What we've seen with StellarSolver is that merging the feature to
master made the branch definitely unstable and untested. It was
bleeding-edge code, but it was sometimes not buildable and often not
usable at all. So my opinion is that we should improve *just a bit* on
this by publishing our new features as minor versions.

If we don't want to create an integration branch, we could prepare
those new very unstable features in solo or collaborative Gitlab MRs,
then update the version in the master branch to the next minor version
when we merge their slightly-more-stable content in. This by no means
forces you to generate an official minor release immediately! It just
inserts a two-step transition for stability.

As an example of MRs as integration branches, have a look at the
colorful Gitlab project list:
https://gitlab.com/gitlab-org/gitlab/-/merge_requests

Besides, CI must support us in always keeping the master branch
buildable. Which means, sorry about this, that we should prohibit
pushes to the master branch.


> 2. PPA Nightly and KDE's Binary Factory nightlies are built from Master. This way users can also try the latest changes.

Yes, in my proposal, there's no need to change that, it works perfectly.


> 3. Once 3.5.0 is released, we can create a branch for it for those who want to use it to build. Meanwhile, master transitions to 3.5.1 Beta immediately.

Yes, in my proposal just like currently, there's no need to keep 3.5.0
in any other form than a tag. And master does transition to a floating
3.5.1 immediately after the 3.5.0 tag is released.

We also need to work to make that release process lighter for you. I
admit I have no idea about what you need to do and how long it takes
you to finish.


> 4. We don't have bug-fix releases in our model (unless something MAJOR is broken). Instead, all fixes AND features go to 3.5.1

My proposal does not add any new treatment related to a bugfix
release. It suggests that you restrain yourself from merging new
features immediately but plan them for a minor version using e.g.
Gitlab Milestones. When we all think the next milestone is attained,
you increase the minor version, zero the patch version and merge all
of the planned feature MRs at the same time in master.

No change for bugfixes, they would still be merged and lead to a new
official release just at the time you decide, planned or not,
milestone or not.


I hope this clarifies the idea.

-- 
-- eric.dejouhanet at gmail.com - https://astronomy.dejouha.net