Simplify bumping Add-on version

[Kirby]

Bumping an Add-on version is a boring, tedious and sometimes quite error-prone routine task:
We either have to edit version_id and version_string in addon.json, pass at least option version-id on the commandline or interactively enter it in the console.

version_id is great for automatic processing, but somewhat hard to read (and way too easy to mess up) for humans.
In most cases, version changes are simple and and predictable, so couldn't this process be simplified?

My suggestion is to make a few changes to this command:

1. Add an new option ---autowith optional values minor and major
   If this option is passed on the commandline, the next version is chosen automatically according to this algorithm:
   If state is stable reset state version to 0 and increase patch version (or minor / major if value is set; remeining version bits are reset to zero if used)
   If state is alpha, beta or rc increase state version, error if that would overflow (eg. state version > 19) or if optional value is set
   Error in all other cases
2. Add a new option --state with optional values alpha, beta and rc
   If this is passed on the commandline together with --auto, state is alpha, beta or rc and no value is set do not increase patch version but increase state version instead, error if that would overflow (eg. state version > 19)
   If one of the optional values is set increase patch version and set state as specified
   Error in all other cases
3. Change the code so version id can be infered from version string if only that is given on the commandline

This would IMHO significantly simplify things - in many cases we could just call

• xf-addon:bump-version --auto --state for hot fixes
• xf-addon:bump-version --auto for normal maintenance updates
• xf-addon:bump-version --auto minor --state beta to start beta for a new minor version or go straight to a new minor version with xf-addon:bump-version --auto minor

 

[bzcomputers]

Agreed, definitely some room for improvement in bumping versions.

Couple additional suggestions:
A) After each build prompt the developer with "Would you like to bump the add-on version now to make it ready for future changes and development?".
B) Offer some "standard" bump options without the developer even needing to enter anything. Show current version_id and version_string and show options:

1. Patch Bump [ID=xxxxxxx] [String=X.X.X XXX]
2. Minor Bump [ID=xxxxxxx] [String=X.X.X XXX]
3. Major Bump [ID=xxxxxxx] [String=X.X.X XXX]
4. Enter Your Own (this would be followed by prompts for version_string and version_id)

 

[bzcomputers]

Not sure of a better place to put this, so here it goes...

I see some flaws in the current add-on bump logic. As it currently sits XenForo recommends that a version is bumped right after a build so that all changes thereafter are attributed to the new version. The issue here is that the developer likely has no idea what size the next build bump will be. Will a bug be reported and it will be a patch? Will the add-on need a new option and a minor release will be required? What if XenForo decides to release 3.0 ahead of schedule and the next build requires a major release to fix all issues to make it compatible with XF 3.0. The developer will not have this kind of information immediately after the last build/release.

Wouldn't it be more convenient to the developer if after any build XenForo just starts tracking all changes without having to do a version bump. Then when the developer makes the decision to build again XenForo can then prompt at the beginning of the build process:

1. Would you like to bump the release version?
2. Would you like to attribute all changes to the previous release X.X.X (warning: this will overwrite the previous release).

This way the add-on release and versioning can never get out sync due to missteps which currently are a little confusing to at least new XenForo developers.

 

[Chris D]

Wouldn't it be more convenient to the developer if after any build XenForo just starts tracking all changes without having to do a version bump.

We literally track changes based on the version ID / string so what you're suggesting isn't really possible without some other identifier that somehow isn't tied to versions. And ultimately this over-engineers a solution to a problem that is fairly trivial.

I agree there can be situations arising from the scenarios you describe but they are generally trivial to mitigate using version control which most serious developers should be. There's obviously a learning curve there but synchronising your code to something like GitHub is at minimum useful for backup purposes.

But once you get used to concepts like branching and merging, it becomes really a non-issue because you can then have multiple versions in active development at the same time.

Naturally sometimes mistakes get made. Believe me. We've done it ourselves. You forget to bump the version and the changes for your next version end up getting attributed to the previous version. But, once again, this becomes more trivial to fix with version control as you can manually fix any versioning mistakes made.

Not commenting either way on the suggestion at this point, but thought it worth addressing this. At the very least, this is a separate discussion and we should keep this thread to discussion about @Kirby's suggestion.