Proposal unify back our release schedules

[Volker Krause]

On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote:
> * We currently don't have a stable branch for Framework and it takes often
> up to one month for fixes to be deployed. The Framework releases is also
> not in sync with either Gear nor Plasma while these two modules heavily
> make use of Framework and contribute to Framework.

The fast feature-releases of KF have major advantages though, comparing to how 
things worked prior to 5. They allow apps to work against released (and thus 
distro-packaged) frameworks while still making it practical to contribute 
needed features to KF directly.

The alternatives are:
* Depend on KF master (like Plasma does), significantly increasing the 
threshold of entry for new contributors, especially for more self-contained 
apps, where you'd now have to build 70+ repos rather than a few.
* Depend on the latest release but develop new features locally rather than in 
KF. I'm not sure whether we have meanwhile finally cleaned up all the forked 
kdelibs classes in PIM from the 3 and 4 era due to that.
* Depend on the latest release and wait for new features to become available 
before making use of them in the app, effectively increasing the delay to reach 
users to twice the release cycle.

Ie. this makes contributing to KF less attractive from an app developer 
perspective.
 

The main issues with out-of-sync KF and Plasma should have been solved with 
some frameworks being moved to Plasma with KF6, if there is more of this 
remaining we should look at the specific cases, for the vast majority of 
frameworks I don't think we have a problem there.

> * Helps with outside usage of our frameworks. These didn't get as much
> success as we were hoping when splitting. I think having a stable branch
> for Framework might help but this is only a guess. It would be interesting
> to know of cases where people considered using some Framework and to know
> why they decided against or for it and if this proposal would helps or not.

I disagree with the often repeated statement that this wasn't successful. It 
might not happened as widely and visibly as we might want, but KF is most 
certainly used vastly more often than kdelibs ever was. And the release 
schedule isn't the impediment here, it's things like dependencies and the 
build system making it hard to vendor copies.

> In effect this proposal would mean:
> 
> * We do one major release every 4 months and then minor releases with a
> frequency based on the Fibonacci numbers as this releases cycle works very
> well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could
> unify that for one or the other one. Or let each component keep their
> current versioning scheme depending whether we want to merge Plama and Gear
> as product or keep it separate. I'm a bit undecided about this.

>From my app developer perspective that is fine, Fibonacci rather than 
equidistant patch releases look like an improvement to me. However, assuming 
the feature release interval basically remains the same.

AFAIK Plasma is discussing a 6 month interval though, and I do understand 
longer cycles are better for promo, but it means users have to wait longer for 
features. It therefore also matters whether we are tying Plasma's release to 
Gear or Gear's releases to Plasma here.

> * "KDE Framework" will still exists as an entity and its ABI and API
>   compatibility requirement. Only change is the release frequency and the
> introduction of a stable branch in sync with the other components.

That part I'm against for the above mentioned reasons, KF's release frequency 
is a major feature of it.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20240419/dfacd22a/attachment.sig>