KStars v3.5.0 Release Date?

[Eric Dejouhanet]

Hello Robert,

Yes, my proposal is that we use patch versions to bugfix minor
versions, and use minor versions for new features. I often read
confusing reports about versions being seen as available which are
actually not official (another one this week in the forum).

Developers usually implement, adjust and review new features supported
by their local build, even for features from other developers. So this
won't really change the way we work today, *except* in the case we
need to cross-compile for the RPi in order to test. That is the
element that would be blocking this proposal, although it is obviously
possible to (slowly) build on the RPi.

I'd consider master as the "current" official version, 3.5.x in our
case, and a branch, named "next" for instance, for any new feature,
3.6 in our case. No patch version allowed in branch "next".

Yes, agreed, end-users would get features later, but potentially far
better integrated and unitary tested.

-Eric

> Hi Eric,
> Ok so then we would be changing the way we do version numbering with this, right?
> I believe now we typically add features in each new iteration 3.4.1, 3.4.2, etc etc
> and when it is really big like StellarSolver, then we make it a big release like 3.5.0
> With this new paradigm, we wouldn’t put new features into the master of the main 3.5 branch
> But instead we would work on a new 3.6 branch, and then bug fixes would go into the 3.5 branch
> to make each new minor release, like 3.5.1, 3.5.2 etc.
> Do I have this correct?
> If this is right, then it would be longer before users see new features in the main branch, but the
> tradeoff is that the main branch would have a LOT more stability.  I see this as a big positive.
> Thanks,
> Rob


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