We’d like to increase the velocity by which we deliver updates, to users (communication of) and would like to do this through release ‘editions/numbers’ - just like Wappler does each Thursday.
I’m just curious, is there a standard practice for such, to determine what is a Wappler 3.8.2 vs a jump to a 3.9 or even a 4.0 - how would this typically be determined? We can do it subjectively, based on the significance of the updates that week/fortnight - just wondering i there is some deeper logic behind it!
Taking v5.4.3 as an example, in my view 5 would be a major release, often not compatible with previous releases 4 would be the addition of extra functionality/security, but still compatible with the major release 3 would be the third revision to remove small bugs/vulnerabilities
In some instances, major releases would not be made for a product, in which case the version would read 4.3
If you are going to follow a continuous deployment or a similar approach to Wappler just use something like Chrome uses. Don’t be afraid to have version 84
Actually the other day I drafted a post about Wappler versioning system as I know they are constrained by the major releases every year.
So some times a major release is tagged as a minor and some times a minor is tagged as a major.
And that is because around May they have to release 4.0 so I think that’s the reason why sometimes it seems so random. I discarded the draft and my proposal because you know…there are just numbers. Who cares?
I’ve questioned some of the version numbers in the past - something major came out as a third-level increment and something less major was at a second-level so didn’t seem to make too much sense. But I now take the same view as @JonL and pretty much ignore the actual numbers.
