semver
semver copied to clipboard
add bump method on version
does it have support for ->bump(SemVer::MAJOR)
or such?
like here https://github.com/vierbergenlars/php-semver/tree/master#functions
https://github.com/vierbergenlars/php-semver/blob/2.x/src/vierbergenlars/SemVer/version.php#L127
<?php
/**
* Increment the version number
* @param string $what One of 'major', 'minor', 'patch' or 'build'
* @return \vierbergenlars\SemVer\version
* @throws SemVerException When an invalid increment value is given
*/
public function inc($what)
{
if ($what == 'major') {
return new version(($this->major + 1) . '.0.0');
}
if ($what == 'minor') {
return new version($this->major . '.' . ($this->minor + 1) . '.0');
}
if ($what == 'patch') {
return new version($this->major . '.' . $this->minor . '.' . ($this->patch + 1));
}
if ($what == 'build') {
if ($this->build == -1) {
return new version($this->major . '.' . $this->minor . '.' . $this->patch . '-1');
}
return new version($this->major . '.' . $this->minor . '.' . $this->patch . '-' . ($this->build + 1));
}
throw new SemVerException('Invalid increment value given', $what);
}
That's not a bad idea.
Thinking about having the SemVer objects be immutable:
// Bump major by 1
$higherSemver = bump($semver, SemVer::MAJOR);
// bump minor by 4
$higherSemver = bump($semver, SemVer::MINOR, 4);
or mutable:
$semver->increase(SemVer::MAJOR);
$semver->increase(SemVer::MINOR, 5);
I'd do the immutable way if there's a need for comparison or anything like that, but prefer the mutable way.
Immutable. Otherwise you run into stuff like this:
<?php
$onePointOne = new SemVer("1.1");
$onePointOne->bump(SemVer::major);
echo $onePointOne;//WTF???
Maybe it's an idea to make a mutable one that extends the immutable SemVer
?
Or, at a given point, be able to freeze the mutable SemVer
thus transforming it into a immutable one (like Symfony does with ParameterBag
).
What benefit would that provide?
To be able to support both
What is the benefit of a maintaining a mutable implementation? To me it seems it will only result in confusion.
Well true, most of the time you would definitely want an immutable SemVer. In the current implementation the Parser
seems to need a mutable though.
In that case adapting the Parser seems to be a more worthwhile adventure. At least in my opinion :smile:.
It probably needs to be refactored and pass the Version metadata through the constructor for an immutable SemVer.