muratgozel / node-calver Goto Github PK
View Code? Open in Web Editor NEWCalendar based software versioning library as node.js module and with cli support. ๐
License: MIT License
Calendar based software versioning library as node.js module and with cli support. ๐
License: MIT License
first thanks for writing this library
I would like to know if you have any plans to support modifiers dev
, alpha
and support additional separators to the dot .
, like -
or _
or simply allow identifiers together, like YYYY0M
let me know if you need more information or prs about it
Great package, thanks for sharing ๐๐ผ
I want to propose adding a build-identifier
option that, if used, would be appended to a modifier. The identifier on previous versions would be ignored when determining next version, and would not affect the current version rolling logic.
This would also comply with semver conventions.
From semver:
Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3โ-117B344092BD.
yy.mm.dd.patch
22.9.10.0
abcd123
A developer is working on the feature deployment branch fixing-stuff
and determined version for the first feature deployment is 22.9.10.1-dev.0
accessible at https://fixing-stuff-abcd123.dev.company.com
. There are several services that participate in the deployment, e.g. sentry
, spinnaker
, et.c.
A build identifier that would become part of of the deployment chain would simplify targeting regressions or broken deployments.
Example version using a build identifier: 22.9.10.1-dev.0+fixing-stuff-abcd123
.
This would allow developers and QA to quickly target where problems were solved (or occurred) during the development phase since it has a human annotation to it ๐
I am up for creating a PR if this makes sense, otherwise I will concat the build identifer to the calver version.
Hi,
When I pass increment
as calendar.minor.rc
to a previous month version without the modifier, the modifier gets set to -1
. I'm not sure if maybe I'm trying something unusual here. I would expect that the following command gives me 2023.3.0-rc.0
.
> const calver = await require('calver')
undefined
> calver.inc("yyyy.mm.minor", "2023.2.2", "calendar.minor.rc")
'2023.3.0-rc.-1'
If I try setting increment
as calendar.rc
, it keeps the minor
:
> calver.inc("yyyy.mm.minor", "2023.2.2", "calendar.rc")
'2023.3.2-rc.0'
Is there a way that I can bump from a version without modifier (with date from a previous month), and get minor=0
and rc=0
?
Thanks!
Currently, it's fixed as UTC. do you have a plan to support timezone?
I am willing to create a PR, but it's better to confirm before I do that.
This project could use some reinvigoration. Mind if I help out as a maintainer? I currently maintain https://github.com/casmith/release-it-calver-plugin, so I have a vested interest in this project's survival.
Hello!
I'm using another Node.js package which leverages this great package to do calendar versioning. I couldn't get it to act like I expected in some cases, and I think this is an oversight in how semantic tags are incremented when (pre-release) modifiers are included.
It centres around whether versions with modifier tags should be considered pre-releases or not, i.e. is 2023.6.0
> 2023.6.0-rc.*
?
To be fair, I can see the argument for modifiers like dev
or alpha
being considered as 'post-release' (2023.6.0-dev.*
> 2023.6.0
), but rc
("release candidate") should definitely be considered as a pre-cursor release to the main unsuffixed version; this is how semantic versioning treats pre-release tags.
Edit: a suggested fix is in PR #22
Here's some examples to illustrate:
๐ก N.b. date now in the following is June 2023
Welcome to Node.js v18.14.2.
Type ".help" for more information.
> c = require('calver')
Calver {
seperator: '.',
levels: [
'CALENDAR', 'MAJOR',
'MINOR', 'PATCH',
'DEV', 'ALPHA',
'BETA', 'RC'
],
_useLocalTime: false
}
> c.inc('YYYY.MM.MINOR', '2023.5.26', 'calendar.minor.rc')
'2023.6.0-rc.0' โ
> c.inc('YYYY.MM.MINOR', '2023.6.0-rc.0', 'calendar.minor.rc')
'2023.6.1-rc.1' โ
My expectation here is that the second example should result in 2023.6.**0**-rc.1
, i.e. the semantic MINOR
tag should not be incremented.
Using calendar.rc
is a workaround to the former case, to avoid incrementing the minor
as well as the rc
tag, but when going from release (no modifier tag) to pre-release (adding -rc.0
), minor
is also needed, in order to increment the minor
semantic tag in the case where the date has not changed, i.e. when adding a pre-release modifier tag, the semantic MINOR
tag should be incremented (or reset, if the date has changed):
> c.inc('YYYY.MM.MINOR', '2023.5.17', 'calendar.rc')
'2023.6.0-rc.0' โ
> c.inc('YYYY.MM.MINOR', '2023.6.0', 'calendar.rc')
'2023.6.0-rc.0 โ
> c.inc('YYYY.MM.MINOR', '2023.5.17', 'calendar.minor.rc')
'2023.6.0-rc.0' โ
> c.inc('YYYY.MM.MINOR', '2023.6.0', 'calendar.minor.rc')
'2023.6.1-rc.0 โ
N.b. obviously the result for calendar.rc
when the date has not changed is technically correct, since the minor
increment was omitted, but my point is that more that it's the 'undesired' result.
> c.inc('YYYY.MM.MINOR', '2023.6.0-rc.0', 'calendar.minor')
'2023.6.1' โ
Similarly, the expected result here is 2023.6.0
, incrementing the pre-release 2023.6.0-rc.0
by calendar.minor
(i.e. dropping the modifier tag) should also not increment the minor semantic tag, because the main release 2023.6.0
is newer than its -rc.*
pre-releases.
Using just calendar
as the increment level is not a practical workaround, since that doesn't work when the date has changed:
> c.inc('YYYY.MM.MINOR', '2023.5.17-rc.0', 'calendar')
'2023.5.17' โ
> c.inc('YYYY.MM.MINOR', '2023.5.17-rc.0', 'calendar.minor')
'2023.6.0' โ
N.b. this is possibly another/different bug? I would have expected calendar
to work here, since the date has changed. It seems to neither reset the minor
tag nor update the calendar
tag.
Hi!
It is not exactly clear to me how calver.inc(format ,version , 'calendar')
is supposed to work.
For example the following test cases scenarios:
assert.strictEqual(calver.inc('yyyy.mm.patch', '2020.6.1', 'calendar'), '2021.1.0')
assert.strictEqual(calver.inc('yyyy.mm.patch', '2021.1.0', 'calendar'), '2021.1.0')
The first line I would expect that the calendar is updated to the current date, and the patch number is reset.
For the second line I would expect to get some kind of error, because the inc doesn't actually increment anything.
Is this supposed to happen?
Exists an issue where when you are using the major, minor and micro, and you increment minor o major (as example), the lower types must be reset to zero, but those types keep their values.
Example:
const calver=new Calver('YYYY.MINOR.MICRO','2020.0.0');
calver.inc('micro');
console.log(calver.get());
// 2020.0.1
calver.inc('minor');
console.log(calver.get());
// 2020.1.1
// In this case must be 2020.1.0
// And the year must be 2021
When I make use of date-based elements in my version tag, I would expect Calver to automatically update these correctly.
Take this example:
const version = new Calver('YYYY.MM.MICRO', '2020.11.3');
version.inc(); // 2020.12.0
const version2 = new Calver('YYYY.MM.MICRO', '2020.12.0');
version2.inc(); // 2020.12.0
The first version number was last created in november (2020-11), since it is december now, it updates to 2020.12.0.
If I want to increase the version number again in december, executing the inc() function returns exactly the same version number. Instead, we'll have to use inc('micro')
to get 2020.12.1.
Maybe I'm missing something, but it seems to me that calver-based version numbers always should be adding one to the micro-level in this case, since the year and month levels did not change from the current version number. Calver knows what day it is, so it can compare it with the current version name to determine what should be updated.
I would expect the following behaviour:
const version = new Calver('YYYY.MM.MICRO', '2020.11.3');
// It is november 15th
version.inc(); // 2020.11.4
// It is november 30th
version.inc(); // 2020.11.5
// It is december 1st
version.inc(); // 2020.12.0
// a later day in december
version.inc(); // 2020.12.1
The last refactor has a major regressed where the feature discussed in #2 is no longer possible.
calver.inc('YY.MM.MINOR', '21.1.0', 'calendar.minor')
Uncaught:
Error: The second tag of the level should be a modifier tag. You specified "MINOR" as the second tag and "CALENDAR" as the first tag.
It seems like this feature was explicitly removed based on the v21.11.0 changelog
Second level might only be a modifier
Just as a reminder, I gave a rationale for why this feature is helpful here: #2 (comment).
I currently have a convoluted way of getting my calendar versioning handled in most of my projects.
First non-(dev,beta,rc) release of the day is tagged/versioned with the date: yyyy.mm.dd
If a second full release is made, for say a hotfix, a suffix is added -1
for example, and is incremented for each subsequent release. This post/hotfix identifier is completely absent if there is only one public release that day. The next day resets to yyyy.mm.dd
On pypi/poetry, when I build and publish with a version like 2024.2.1-1
creates a version on pypi 2024.2.1.post1
with no manual input required.
These are uploaded to pypi and not treated as pre-releases.
I do not have dev,rc,beta builds uploading yet, but I want to get pre-releases up so my users can test it before it goes out wide.
https://pypi.org/project/sickchill/#history
It would be awesome if just calling
with today = 2024.2.1
calver.inc(format, '', 'calendar.post')
returned '2024.2.1'
,
calver.inc(format, '2023.2.1', 'calendar.post')
(previous date) returned '2024.2.1'
,
calver.inc(format, '2024.2.1', 'calendar.post')
returned '2024.2.1.post1'
,
calver.inc(format, '2024.2.1.post1', 'calendar.post')
returned '2024.2.1.post2
and possibly add a nulpost
(or something of that nature) modifier that would accept and create a post level without modifier words:
calver.inc(format, '', 'calendar.nulpost')
returned '2024.2.1'
,
calver.inc(format, '2023.2.1', 'calendar.nulpost')
(previous date) returned '2024.2.1'
,
calver.inc(format, '2024.2.1', 'calendar.nulpost')
returned '2024.2.1-1'
,
calver.inc(format, '2024.2.1-1', 'calendar.nulpost')
returned '2024.2.1-2
Also, note my nulpost has a -
separator and pypi converts it to .
= maybe a parameter for modifier-level separator?
I'm interested in writing a github action to make this simple for python users to use, and keep both a release branch and a dev/rc branch uploaded to pypi with pre-releases. So any help getting this library to work in the odd way I am trying to make it fit me lmk lol. Thanks.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.