Skip to content

Commit

Permalink
Now use minor version instead of date
Browse files Browse the repository at this point in the history
  • Loading branch information
@jimmywarting
jimmywarting committed May 25, 2016
1 parent 1be5622 commit a6d1199
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion FileSaver.js
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
/* FileSaver.js
* A saveAs() FileSaver implementation.
* 1.1.20160520
* 1.2.0
*
* By Eli Grey, http://eligrey.com
* License: MIT
Expand Down

8 comments on commit a6d1199

@eligrey
Copy link
Owner

@eligrey eligrey commented on a6d1199 May 26, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dates (in the format I used) can be minor versions in semver. I'm okay with semver since I have made small API changes. I probably won't use dates in the future, but understand that they are valid semver.

@jimmywarting
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me 1.1.20160526 looks long and weird. it wouldn't work with hotfix if you would do something the same day

@eligrey
Copy link
Owner

@eligrey eligrey commented on a6d1199 May 27, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can always do 1.1.20160526.1 :P

Actually, if semver doesn't support 4 levels then I guess you could also do 1.1.20160526+1, since I think + is valid (for metadata and build stuff usually)

@jimmywarting
Copy link
Collaborator Author

@jimmywarting jimmywarting commented on a6d1199 May 27, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD 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.

http://semver.org/#spec-item-10

@eligrey
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, thanks for the info.

@Daniel15
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what it's worth, I liked the use of dates. It made it easy to tell if I was on a very old version of the library :)

What about writing something like "1.1.1 (released 2016-05-20)" - ie. both the minor version and the date.

@jimmywarting
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Daniel15 then just look at the release tags

A semantic version number is better for npm and bower, and also for keeping it up to date with what can be/is a breaking change patch or a feature

@eligrey
Copy link
Owner

@eligrey eligrey commented on a6d1199 Jun 13, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used a combination of date + an appended number for multiple releases on the same date. A date is a perfectly valid minor version number as long as it's in the right format (e.g. YYYYMMDDR). I don't really care much what the format currently is. Just clearing up that dates can be valid here.

Please sign in to comment.