KStars v3.5.0 Release Date?

[Robert Lancaster]

Maybe as a compromise between the two plans would be if we have really big features or huge changes, to just work on them and share the changes back and forth in a branch, and then when it gets stable, then integrate that into Master?

> On Nov 5, 2020, at 1:53 PM, Wolfgang Reissenberger <sterne-jaeger at openfuture.de> wrote:
> 
> Hi Jasem,
> I fully agree, the simplicity of the approach makes It easy to manage. 
> 
> The downside is, that it is difficult to introduce bigger features which by nature take longer to get stable - as we just see with the great idea behind StellarSolver. Our current approach sets us heavily under pressure to stabilize it and we have no way how to deliver bug fixes on the stable version.
> 
> Maybe it makes sense to discuss how we could bring our development approach forward that remains simple but gives us more flexibility for new features.
> 
> Wolfgang
> 
>> Am 05.11.2020 um 18:11 schrieb Jasem Mutlaq <mutlaqja at ikarustech.com <mailto:mutlaqja at ikarustech.com>>:
>> 
>> Thank you all for sharing your thoughts on this issue. Here are my thoughts.
>> 
>> 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.
>> 2. PPA Nightly and KDE's Binary Factory nightlies are built from Master. This way users can also try the latest changes.
>> 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.
>> 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
>> 
>> This makes the whole cycle simpler and easier to manage IMO. The primary issue we have for now is that we don't have tight releases schedules, so some releases take 4 weeks, while others 12 weeks..etc.
>> 
>> --
>> Best Regards,
>> Jasem Mutlaq
>> 
>> 
>> 
>> On Thu, Nov 5, 2020 at 7:18 PM Robert Lancaster <rlancaste at gmail.com <mailto:rlancaste at gmail.com>> wrote:
>> 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 <mailto: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 <mailto:eric.dejouhanet at gmail.com> - https://astronomy.dejouha.net <https://astronomy.dejouha.net/>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20201105/e8aa6862/attachment.htm>