KStars v3.5.0 Release Date?

[Jasem Mutlaq]

Yes that would work well. It could go into a branch until it's deemed
somewhat stable then moved back to master for general testing.

--
Best Regards,
Jasem Mutlaq



On Thu, Nov 5, 2020 at 10:04 PM Robert Lancaster <rlancaste at gmail.com>
wrote:

> 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>:
>
> 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>
> 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>
>> 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20201105/eeeb01b7/attachment-0001.htm>