KStars v3.5.0 Release Date?

[Robert Lancaster]

Yes, I like this idea very much because it does mean that everything gets more stable.
I really like all the features we have been adding and all the cool stuff we have been doing,
but the problem is that a number of people build directly from master, and need a reliable version.
They do want the bug fixes to fix problems they are having, but they do not want more bugs from unfinished work.
When a feature isn’t ready yet and we need to share it with others and work on it together in order to test things and get them working, 
we should have a separate branch in which we can work on this stuff and not have people relying on it for real yet.

It is true that in our current design we have stable releases, but the stable releases often need bug fixes and if the bug fixes get mixed
in with the new features, then users have to choose whether to upgrade and get new bugs to get rid of old bugs, or not upgrade and not get the bug fixes.

So yes I think this is a positive.  Good idea!

Thanks,

Rob

> On Nov 5, 2020, at 8:06 AM, Eric Dejouhanet <eric.dejouhanet at gmail.com> wrote:
> 
> 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