a original version, which will be developed and versions of it will be released
a "community edition" of this version, which is based on the original version, but additional features or changes may be included
a situation where the community version will still be updated with new official version releases by integrating them into the CE version.
That's why it would be good to have both version numbers - the "official one" and the "forked one" together in one version number so you can see them both at a glance.
However I do not know whether that's possible.
If so what do you think would be the best way to do this? Some thoughts/ideas of me and a contributor you can find in the issue linked above.
Originally created by @rugk on GitHub (Nov 3, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/278
Abstracting https://github.com/rugk/threema-msgapi-sdk-php/issues/3...
We have:
- a original version, which will be developed and versions of it will be released
- a "community edition" of this version, which is based on the original version, but additional features or changes may be included
- a situation where the community version will still be updated with new official version releases by integrating them into the CE version.
That's why it would be good to have both version numbers - the "official one" and the "forked one" together in one version number so you can see them both at a glance.
However I do not know whether that's possible.
If so what do you think would be the best way to do this? Some thoughts/ideas of me and a contributor you can find in the issue linked above.
Okay, the only difference I see is that the other issues work with channels. We of course also have different channels, but the version number of both should be included in the new whole version number.
E.g. 1.1.2@CE.0.1 instead of just 1.1.2@CE.
<!-- gh-comment-id:153478091 -->
@rugk commented on GitHub (Nov 3, 2015):
Okay, the only difference I see is that the other issues work with channels. We of course also have different channels, but the version number of _both_ should be included in the new whole version number.
E.g. `1.1.2@CE.0.1` instead of just `1.1.2@CE`.
@rugk, you can use a build meta tag to encode the other version. No need for a new kind of field in the SemVer spec. Unless you have further questions or intend to issue a PR linked to this issue, please close it at your earliest possible convenience.
<!-- gh-comment-id:350419572 -->
@jwdonahue commented on GitHub (Dec 9, 2017):
@rugk, you can use a build meta tag to encode the other version. No need for a new kind of field in the SemVer spec. Unless you have further questions or intend to issue a PR linked to this issue, please close it at your earliest possible convenience.
If anyone is wondering for a quick solution to this, personally I just appended a part of my username to the versions, e.g. itr-1.4
<!-- gh-comment-id:1870697553 -->
@iTrooz commented on GitHub (Dec 27, 2023):
If anyone is wondering for a quick solution to this, personally I just appended a part of my username to the versions, e.g. `itr-1.4`
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @rugk on GitHub (Nov 3, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/278
Abstracting https://github.com/rugk/threema-msgapi-sdk-php/issues/3...
We have:
That's why it would be good to have both version numbers - the "official one" and the "forked one" together in one version number so you can see them both at a glance.
However I do not know whether that's possible.
If so what do you think would be the best way to do this? Some thoughts/ideas of me and a contributor you can find in the issue linked above.
@FichteFoll commented on GitHub (Nov 3, 2015):
This is a long-standing discussion. See #264, #265 (probably more).
@rugk commented on GitHub (Nov 3, 2015):
Okay, the only difference I see is that the other issues work with channels. We of course also have different channels, but the version number of both should be included in the new whole version number.
E.g.
1.1.2@CE.0.1instead of just1.1.2@CE.@jwdonahue commented on GitHub (Dec 9, 2017):
@rugk, you can use a build meta tag to encode the other version. No need for a new kind of field in the SemVer spec. Unless you have further questions or intend to issue a PR linked to this issue, please close it at your earliest possible convenience.
@iTrooz commented on GitHub (Dec 27, 2023):
If anyone is wondering for a quick solution to this, personally I just appended a part of my username to the versions, e.g.
itr-1.4