- Affected version
- 2.2.3pl1
Incorrect output:
Correct output:
Correct output:
Closed xf-addon:bump-version requires zerofill to parse version IDs below 1.0.0
- Thread starter DragonByte Tech
- Start date
This is not really something we can safely change.
We have to accept that some developers don't want to use our version ID format, and it's not something we really try to force people use, even though we recommend it.
For other developers, a version ID of
If anything, there is a bug here which is that we shouldn't allow version IDs to be specified that are prefixed with zero.
With that in mind, you'll need to continue specifying the version ID as
Of course, what we'd actually recommend is that you start your versioning at
FWIW during development of XF 1.0 our version IDs started at
We have to accept that some developers don't want to use our version ID format, and it's not something we really try to force people use, even though we recommend it.
For other developers, a version ID of
118 might actually mean 1.1.8 and so forcing that to suddenly mean 0.0.1 Alpha 8 doesn't seem ideal.If anything, there is a bug here which is that we shouldn't allow version IDs to be specified that are prefixed with zero.
0000118 is not a valid integer and we expect it to be for version comparisons.With that in mind, you'll need to continue specifying the version ID as
118 and accept that you'll have to write the version string out manually to mean what you want.Of course, what we'd actually recommend is that you start your versioning at
1.0.0 Alpha 1 which can be written as e.g. 1000018 for Alpha 8 as this is more semantically correct.FWIW during development of XF 1.0 our version IDs started at
1000011 so we don't directly have an expectation to support versions starting at version 0.0.0 with this system.
Fair enough, 99% of cases I wouldn't expect using 0.0.1 as a starting version, but this is a project that needs to be deployed frequently to a test site and I'd like to use the standard upgrade step procedure rather than manually altering the database / SSHing in to run update commands 
Please don't change the zerofill though cause that's gonna make bumping this version harder
Please don't change the zerofill though cause that's gonna make bumping this version harder
If you're starting with version 1.0.0 Alpha what's stopping you from using the standard upgrade step procedure? There is a limiting factor I suppose in that a version ID suffix from 10 to 29 are the only valid "Alpha" versions so I suppose if you're planning to have more upgrade versions than that then I see your point.Fair enough, 99% of cases I wouldn't expect using 0.0.1 as a starting version, but this is a project that needs to be deployed frequently to a test site and I'd like to use the standard upgrade step procedure rather than manually altering the database / SSHing in to run update commands
Please don't change the zerofill though cause that's gonna make bumping this version harder
Yeah I think we're ok. I hadn't actually tested it yet but it seemed to me like it might be possible that it was generating and saving a version ID of
0000118 which would be invalid.So for now we'll just close this as "as designed".