Determine Cypht's lifecycle

[marclaporte]

Related:

• https://github.com/cypht-org/cypht/wiki/Lifecycle
• Lifecycle, requirements/dependencies and Long Term Support (LTS) versions #431

[jonocodes]

It sounds like that doc is a new scheme not yet in use.

And it looks like it's leaning toward scheduled releases where the numbers changed based on time, not features.

Semantic versioning is different in that the numbers communicate compatability between releases. For example you may introduce a dB schema change that will not gracefully work from one version to the next. The version number will communicate that.

But in both of the above schemes every specific version number represents a single point of time in the repo. This means if you are at v1.2 and you have fix a bug you would probably release 1.3 or perhaps 1.2.1. You would not backport into version 1.2. This is because when someone has an issue with 1.2 you don't know exactly which 1.2 they are talking about.

If you are concerned that when using an x.y.z pattern someone will just want the latest 1.2.? That can be handled by a package manager or using certain tagging conventions in docker.

I can give more details if interested.

[marclaporte]

It sounds like that doc is a new scheme not yet in use.

Correct.

[marclaporte]

And it looks like it's leaning toward scheduled releases where the numbers changed based on time, not features.

Right. I see what you mean. But if there are always major features every 6-8 months. And there is always one of these major features that lead to incompatibility, do we not end up with semantic versioning by accident?

[marclaporte]

Some context:

I have been involved in Tiki for over 20 years, so I have a Tiki-centric view of things. So I am glad to learn about how we can do things differently.

Tiki has been using a time-based release process for 15 years now, and it has worked really well: https://tiki.org/Lifecycle
However, Tiki is much bigger and more complex than Cypht, so the solution can be quite different.

Here is what I project for the future, to help pick the best model:

• For most of Cypht's life, it was mostly a one-developer project. For the coming years, it will be 10 to 15 devs
  -- https://openhub.net/p/cypht/contributors/summary
  -- https://unencumberedbyfacts.com/2023/06/14/cypht-rebooted/
• For the foreseeable future, the Tiki developers will be the most active, but Cypht remains an independent project, and we want to grow the community and have plenty of developers that use Cypht as standalone, or that plug into other projects.
• I see a lot of potential for Cypht as a "pluggable webmail" for PHP projects. Cypht is already the most popular webmail here: https://packagist.org/?query=webmail
• Here is a view of this ecosystem in 2024: https://wikisuite.org/Webmail-and-groupware-comparison

[jonocodes]

Ok. Good info on the context.

Still, what you are describing it not semantic versioning. It violates points: 2, 3, 6, 7, 8 in the spec: https://semver.org/

That being said you certainly dont need to use semantic versioning. I tend to use since it is a common standard many devs know.

Time based releases can be fine, but I dont think you should try to adhere to both schemes at the same time.

But point 3 of the semantic versioning spec I think is important across versioning systems:
"Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version."

I believe this conflicts with the backporting mention in your doc:
"All commits start in master, and bug fixes can be backported to the stable branch."

Though maybe I am not understanding what that means. Also the tiki lifecycle does not mention backporting.

Since it looks like you are leading toward time based with x.y numbers, I recommend:

1. Remove mentions 'semantic versioning' from the doc.
2. All updates (features or bug fixes) require a new version.

For example, lets say the latest version is 4.1. If you do a monthly release, you up the minor version: 4.2
Then if you do a bug fix you release a new version: 4.3
The next week you find a bunch of critical bugs each day that should be released right away: 4.4, 4.5, 4.6, 4.7
Now 8 months passes and you release 5.0.
2 days later there is a critical bug and you release 5.1. I suppose thats when 4.x goes out of support based on your life cycle.

If you think mixing feature releases with bug fix releases is confusing to users, then introduce another digit (x.y.z) into your scheme.

[marclaporte]

Also the tiki lifecycle does not mention backporting.

Covered here: https://dev.tiki.org/Where-to-commit

[marclaporte]

But point 3 of the semantic versioning spec I think is important across versioning systems:
"Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version."

I agree 100%. This is how we've always been doing for Tiki and Cypht. I didn't specify it because I don't remember ever seeing a project that violates point 3. That would be quite chaotic.

[marclaporte]

I believe this conflicts with the backporting mention in your doc: "All commits start in master, and bug fixes can be backported to the stable branch."

Though maybe I am not understanding what that means.

1. Remove mentions 'semantic versioning' from the doc.

ok, I clarified https://github.com/cypht-org/cypht/wiki/Lifecycle

Please just edit it further to make it clearer.

Thanks!

[jonocodes]

To clarify, what is a "stable" branch? Is that everything after 1.0?

[marclaporte]

Yes

[jonocodes]

Also the tiki lifecycle does not mention backporting.

Covered here: dev.tiki.org/Where-to-commit

Ah, I missed that. But I could use a concrete example.

In cypht, lets say the latest version is 4.3 and we find a bug that was introduced 6 releases ago. What exact versions would that fix get 'backported' to? And what new versions would that create?

[marclaporte]

In cypht, lets say the latest version is 4.3 and we find a bug that was introduced 6 releases ago. What exact versions would that fix get 'backported' to? And what new versions would that create?

It is fixed in master, and then backported to 4.x for a release of 4.4

3.x is EoL at this point so we don't backport there.

[marclaporte]

While releasing Cypht 2.0, @kroky decided to keep x.y.z format:
https://github.com/cypht-org/cypht/releases/tag/v2.0.0

So after 2.0.0, we have the choice of 2.0.1 or 2.1.0

I updated: https://github.com/cypht-org/cypht/wiki/Lifecycle

[marclaporte]

I updated https://github.com/cypht-org/cypht/wiki/Lifecycle some more but it still needs some fixes to clarify that 2.0.x is no longer supported once 2.1.0 is released.

Chronologically:

We will do normally do:
2.0.0 > 2.1.0 > 2.2.0 -> 2.3.0

Exceptionally, we may do:
2.0.0 -> 2.0.1 -> 2.1 -> 2.2 -> 2.3

But we will not do:
2.0.0 -> 2.0.1 -> 2.1 -> 2.0.2 -> 2.2 -> 2.3

[jonocodes]

I updated https://github.com/cypht-org/cypht/wiki/Lifecycle some more but it still needs some fixes to clarify that 2.0.x is no longer supported once 2.1.0 is released.

Chronologically:

We will do normally do:
2.0.0 > 2.1.0 > 2.2.0 -> 2.3.0

Exceptionally, we may do:
2.0.0 -> 2.0.1 -> 2.1 -> 2.2 -> 2.3

But we will not do:
2.0.0 -> 2.0.1 -> 2.1 -> 2.0.2 -> 2.2 -> 2.3

OK. My only recommendation here is to always use 3 digits. So instead of 2.1 you use 2.1.0

[kroky]

I added some clarification about releases.

[marclaporte]

@jonocodes How does https://github.com/cypht-org/cypht/wiki/Lifecycle diverge from https://semver.org now?

[jonocodes]

Its certainly closer to semantic but not quite there. Mostly because the major number is strictly time based.

I would not try to do both schemes. What you are using now seems pretty common (see Firefox, Thunderbird, Ubuntu...)

I can think of a way of doing both schemes but it would weaken the time based part and would disrupt the LTS scheme, so its probably not worth it.

[marclaporte]

Its certainly closer to semantic but not quite there. Mostly because the major number is strictly time based.

I had removed the time-based part:
https://github.com/cypht-org/cypht/wiki/Lifecycle/_compare/5a872a8180fc8be329238062b63fd72ddb6e909f...00c7e374a1c600bd374c46b88cd138887b7d2532

[jonocodes]

Its certainly closer to semantic but not quite there. Mostly because the major number is strictly time based.

I had removed the time-based part: Wiki: Lifecycle/_compare/5a872a8180fc8be329238062b63fd72ddb6e909f...00c7e374a1c600bd374c46b88cd138887b7d2532 ()

Ah, I missed that. Sounds good.
Not sure the best way to mark LTS releases though since the numbers are no longer predictable.

[marclaporte]

One thing I am wondering about SemVer:

Does increasing the minimum required PHP version provoke a major release?

Sooner or later, we will drop PHP 7.4, and require 8.1, 8.2 or 8.3:
#977

Say we are at Cypht 2.2.0, and the next release should be 2.3.0 (new features but no breaking changes), and for whatever reason, we decide to bump the PHP requirements from PHP 7.4 to 8.1, does this mean we should release as 3.0.0 instead?

This is a bit theoretical because we would normally bump the requirements early in the cycle so developers can take advantage of PHP 8.x. And we may leverage https://github.com/symfony/polyfill to use the latest and greatest while maintaining support for older PHP versions. And in doing all this, we'll likely make big enough changes to justify a major revision.

[jonocodes]

Good question.
You dont need to update the major digit for this, but I think it would not hurt. When in doubt its ok to play it safe and bump that number.
Side note. I finally got cypht up and running locally today outside of docker and there were a couple blank pages on the site. I dont know the issues yet but it could be the php version since the earliest php my distro has is 8.1.

[marclaporte]

When in doubt its ok to play it safe and bump that number.

Makes sense to me.

I dont know the issues yet but it could be the php version since the earliest php my distro has is 8.1.

Yes, it could be. But it could just be a basic bug because 2.0.0 is buggy: https://github.com/cypht-org/cypht/releases/tag/v2.0.0

[marclaporte]

Our lifecycle will likely change (to determine time span for LTS versions) but in general that page describes well how things will work for the coming months/years. So I am closing this task.

@jonocodes I restored Semver with a warning:
https://github.com/cypht-org/cypht/wiki/Lifecycle/_compare/0079919bcc38101da7e308cec5ea3d33be102382...109f8f1a546e10146ac5ba20bd0ef938f035132b

[marclaporte]

I also added an LTS: https://github.com/cypht-org/cypht/wiki/Lifecycle

[kroky]

Dropping major PHP version support is worth releasing a new major cypht version. Otherwise, it might be confusing as people usually add composer dependencies in a form of ^2.0 to depend on any cypht v2 and if we drop php 7.4 support from 2.2 to 2.3, their upgrade will fail (or keep them at 2.2 which might be confusing).