WBCE CMS Forum

cwsoft

Mitglied

WBCE versioning

@Norhei: Dachte wir machen ne semantische Versionierung. Dort würde jetzt 1.1.0-Beta2 stehen. Der Bugfixlevel würde erst hochgezählt, nachdem die 1.1.0 stable veröffentlicht wurde. Sprich Alpha 1-x, dann Beta 1-x, dann RC 1-x, dann stable 1.1.0, 1.1.1-1.1.x ...

---

Account inactive since 2018/11/17.

norhei

Developer

Re: WBCE versioning

hmmmm... hatte das so verstanden das man das machen kann , persönlich find ich das praktischer ohne  und das version compare script kann auch einfacher sein

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

florian

Administrator

Re: WBCE versioning

I was a bit puzzled about the 1.1.1 too. We should strongly avoid to run into the same chaos as WB does. So I would prefer that we currently have the releases 1.0.0 stable and 1.1.0 beta-2, followed by 1.1.0 RC, and when we are brave enough to release the next stable version, 1.1.0 final. If necessary (due to a nasty bug or a security flaw), we coeld release a 1.1.1, but for me the following version of 1.1.0 beta-1 actually would be an 1.1.0 beta-2.

norhei

Developer

Re: WBCE versioning

try to write a correct version checker for
1.0.0-pre.alpha,1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-alpha.2, 1.0.0-beta, 1.0.0-beta.1, 1.0.0-beta.2,  1.0.0-RC, 1.0.0-RC.1, 1.0.0-RC.2,

Personally i feel its far more easy
1.1.0 , 1.1.1, 1.1.2 ......

Leaving all stuff like beta, alpha ... only to the description of the release maybe display it somewhere in the BE.

What we do if we decide to add a feature in beta state or maybe even need to breake whith something.
Example we add a feature in Apha stadium
The initial Alpha       1.1.0 alpha
Now we add a feature so basically we need to increase the second Number

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

1.1.0 alpha is followed by    1.2.0-alpha.2 ??

Maybe we even need to remove something.
1.2.0-alpha.2 is followed by  2.2.0-alpha.3

As off :

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

For the first release this was no problem as it did not matter , every Release was 1.0.0 but if we want to follow Semantic versioning we need to increase Version number in any release?

Another thing is to make sure the version compare really can handle 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.. ....

Reading through the Semantic versioning again , i think both ways are valid.   
Increasing numbers on every release or using Alpha,beta,RC.

Writing all this i think the versioning process needs some more clarification. The last release was pretty urgent as there have been some ugly security issues and i tried to discuss this whith CWsoft , but not knowing when he is online again , we decided to release.

Btw. we schould write some words about the whole  release Process
Something like
1. declare feature freeze, Fork off a branch , all new features no go into master only fixes go into branch.
2. set version number depending on feature freeze
3. release alpha.1.2.3.4.....
4. release beta.1.2.3.4....
5. release RC.1.2.3.4.5....
6. If there is a reason to add features or break things increase version number
for example 1.2.3-alpha.1 is just a bugfix release but we need to add a new feature to fix the bugs
so it becomes 1.3.0-alpha ?
7. if RC runns sucessfully go and release  1.3.0(or 1.2.3 depending on 6)

Something like that whith a few examples would be great.

cwsoft

Mitglied

Re: WBCE versioning

For me its easier than that. Alpha, Beta, RC means that the future version is not yet ready and still in development/testing&bugfixing/final evaluation. If we stick to a version string like major.minor.bugfix[-alpha|beta|rc[0-9]] its easy to write a version compare for it.

Just bear in mind. We are not WB and we can establish our own rules for WBCE. For backwards compatibility with other WB modules, we could check the version string during installation process (WBCE) and throw a notice if the version string is not WBCE compatible. To get such an Addon working, one would fix the version string and install the Addon.

In the ZEN of Python there is on rule. In the face of ambiguity, refuse the temptation to guess.
https://www.python.org/dev/peps/pep-0020/

Beitrag geändert von cwsoft (21.11.2015 19:33:10)

---

Account inactive since 2018/11/17.

florian

Administrator

Re: WBCE versioning

(posts about versionining moved to this new topic)

As far as I know, most other systems only increase even the subversion number for releases. This forum, for example, runs with FluxBB 1.5.9, and the 9 is not the 9th attempt to release a stable 1.5. The same at phpBB, (although this a not a so good example due to updating phpBB even from minor versions is a real horror).
So we should not invent new versioning systems but use a common standard. That's my opinion as a non-developer, maybe I see this too simple, but anyway I see this from the user's perspective for whom I consider it is more easy to trust in WBCE when he does not download buggy or instable development versions by mistake.

cwsoft

Mitglied

Re: WBCE versioning

I would stick to semantic versioning including alpha/beta/rc tags to highlight the maturity level of the release. If we just do a bugfix for an official release, we don't need alpha/beata/rc. But if we release a new next version with lots of changes, beta/rc pre-releases make perfectly sense.

https://blog.selfhtml.org/2013/11/08/se … ung-2-0-0/

Regardless of which version system we will finally use. We should agree fast and then simply stick to our rules. Actual situation is not very clear and transparent.

---

Account inactive since 2018/11/17.

cwsoft

Mitglied

Re: WBCE versioning

@norhei: Regarding the branch stuff at Git/Github. I do stick to the rule, that the master branch is always the latest up-to date one. Commits to the master branch should never break the system, meaning that a commit should always include all the files needed to implement one feature or bugfix at one time. Locally one can work with more commits, but should do an squash and bundle those commits into one logical commit before pushing to the master at Github to keep the history clean.

Regarding bugfixing and branching. In Git a branch is just a tag nothing more. This means if the master e.g.is at WBCE 1.2.0 and we find a bug which needs to be fixed in 1.1.0, we would just create a branch from the tag v1.0.0 and push the fixes to the new branch. If there is no fix for a given version, there is no need for a seperate branch, as the version tag by default is a kind of branch already.

There are lots of different models available at Github one could follow. We just need to agree on one release model and stick to it. I never used the SVN concept of master/trunk etc. since working with Git/Github - it was just not necessary :-)

---

Account inactive since 2018/11/17.

norhei

Developer

Re: WBCE versioning

About versioning:
Ok lets do it like obviously most pepole thing its going , but please write it down whith examples.
We need an exact definition or things will go wrong if we are in a hurry.

Basic semantic versioning whith http://semver.org/ using the option for releasenames.
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.. ....

Version only is increased  on first prerelease .
Version 1.1.2 old stable.
New Version  1.2.0-alpha .....

Upgrades in same release state are seperated by a dot like described in semver.org
1.2.0-alpha
1.2.0-alpha.1
1.2.0-alpha.2
1.2.0-alpha.3

prerelease states are :
alpha, beta, RC

There is still one question left , what we do if it becomes necessary to add features in a bug release or maybe break something in a feature release , while in prerelease state .  Basically we should avoid this , but sometime this may become necessary.

Example:
1.2.0-alpha.2 and suddenly we realize we need to move frontendfunctions to a module , breaking core compatibility . Just going to 1.2.0-alpha.3 is not semantic. Do we go to  2.0.0-alpha ? Or what else.

1.1.1-beta and we suddenly realize that we need to add a new loginclass as the old one is a security nightmare. The new class add some features, what to do?

Please open  a different thread  for move SVN/Git conventions , mixing this is not a good idea!

cwsoft

Mitglied

Re: WBCE versioning

@norhei: Moving frontend functions to a module wouldn't change the public API if we ship the module, hence we go for 1.2.0-alpha3.

I would recommend sticking to semantic versioning and to use alpha/beta/rc for pre-releases only, always starting with #1 as the first release (for sorting algorithm) and just increase the last number with each subsequent release until we reach stable.

If we change the API and regognize it late in the process, we just release a 1.3.0-alpha1 with the first release introducing the API changing modification. In case of small releases with just one or two changes, we can also skip the alpha/beta/rc and just increase the version number accordingly. However, the changes introduced between 1.0.0 and 1.1.0 are way to much so I would start with the beta and rc phase.

Cheers

P.S: sticking to major.minor.bugfix[alpha|beta|rc]N would allow to use PHP functions for the comparison without the need to write custom code http://php.net/manual/de/function.version-compare.php

Beitrag geändert von cwsoft (23.11.2015 09:33:29)

---

Account inactive since 2018/11/17.

norhei

Developer

Re: WBCE versioning

Huhu, CWsoft i can't reach you, your mailaddress seems to be broken!!! especially the gmx one.

cwsoft

Mitglied

Re: WBCE versioning

@norhei: Thanks for reporting. Issue fixed.

---

Account inactive since 2018/11/17.

norhei

Developer

Re: WBCE versioning

Cwsoft and i found some time to work out a functional versioning scheme that uses semantic versioning as a basis.
The original document needed quite a few clarifications as many paragraphs are optional and/or can be interpreted entirely different.

This weekend i found time to write it all down.

Edit: Download deleted,  see next post.

norhei

Developer

Re: WBCE versioning

Actually i put the documents into github repo for easy management.
https://github.com/WBCE/Versioning-Scheme