New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support versioning librarys via semver #410

Closed
FWeinb opened this Issue Dec 29, 2015 · 10 comments

Comments

Projects
None yet
4 participants
@FWeinb

FWeinb commented Dec 29, 2015

For proper versioning adapting semver would be great. Currently it looks like the commit hash is used to identify the version of a library.

I think this would greatly improve the ecosystem for using third-party libraries with platformio.

@marvinroger

This comment has been minimized.

Show comment
Hide comment
@marvinroger

marvinroger Jan 3, 2016

This should apply to both library.json and platformio.ini, right? What about doing it like so:

  • 1.2.3 would match exactly 1.2.3
  • ~1.2.3 would match 1.2.x
  • ^1.2.3 would match 1.x.x

This is the npm way of doing semversionning, and this is pretty clean and straightforward, I think.

marvinroger commented Jan 3, 2016

This should apply to both library.json and platformio.ini, right? What about doing it like so:

  • 1.2.3 would match exactly 1.2.3
  • ~1.2.3 would match 1.2.x
  • ^1.2.3 would match 1.x.x

This is the npm way of doing semversionning, and this is pretty clean and straightforward, I think.

@ivankravets

This comment has been minimized.

Show comment
Hide comment
@ivankravets

ivankravets Jan 3, 2016

Member

@marvinroger Sure, see #410 (comment) and semver.

Member

ivankravets commented Jan 3, 2016

@marvinroger Sure, see #410 (comment) and semver.

@marvinroger

This comment has been minimized.

Show comment
Hide comment
@marvinroger

marvinroger Jan 3, 2016

Well, I am commenting on #410... But the semver spec doesn't actually define range specifiers.

marvinroger commented Jan 3, 2016

Well, I am commenting on #410... But the semver spec doesn't actually define range specifiers.

@ivankravets

This comment has been minimized.

Show comment
Hide comment
@ivankravets

ivankravets Jan 3, 2016

Member

Opss... Sorry. See what do we have in Python world: https://pypi.python.org/pypi?%3Aaction=search&term=semver&submit=search

Which package do you recommend?

Member

ivankravets commented Jan 3, 2016

Opss... Sorry. See what do we have in Python world: https://pypi.python.org/pypi?%3Aaction=search&term=semver&submit=search

Which package do you recommend?

@marvinroger

This comment has been minimized.

Show comment
Hide comment
@marvinroger

marvinroger Jan 3, 2016

No problem!

The thing is semver is not MAJOR.MINOR.FIX, it is BREAKING.FEATURE.FIX, so most people will want to match 1.x.x, so their code benefits from new features and patches, without breaking changes.

The semver package provides these specifiers : <, >, ==, <= and >=, and its function to check if a version match against a range can only check one specifier at a time. So the end user would have to set >=1.0.0 <2.0.0, and you would have to split this string on spaces, check if all specifiers match for every version registered on the server, and return the highest matching version. Painful, both to you and the end user.

node-semver on the other hand, is way easier to deal with. It supports multiple specifiers, and the end user can use <, >, ==, <= and >=, but also -, x, *, ^ and ~. In other words, to express the above need, the end user could set:

  • >=1.0.0 <2.0.0
  • 1.x.x or 1.*.* or event lighter : 1.x, or 1
  • ^1.0.0

More info on node-semver

And the code looks like:

from semver import max_satisfying

versions = ['1.2.3', '1.2.4', '1.2.5', '1.2.6', '2.0.1']
range_ = '^1.0.0'
assert max_satisfying(versions, range_) == '1.2.6'

So I'd definitely recommend node-semver. Easier for everyone!

marvinroger commented Jan 3, 2016

No problem!

The thing is semver is not MAJOR.MINOR.FIX, it is BREAKING.FEATURE.FIX, so most people will want to match 1.x.x, so their code benefits from new features and patches, without breaking changes.

The semver package provides these specifiers : <, >, ==, <= and >=, and its function to check if a version match against a range can only check one specifier at a time. So the end user would have to set >=1.0.0 <2.0.0, and you would have to split this string on spaces, check if all specifiers match for every version registered on the server, and return the highest matching version. Painful, both to you and the end user.

node-semver on the other hand, is way easier to deal with. It supports multiple specifiers, and the end user can use <, >, ==, <= and >=, but also -, x, *, ^ and ~. In other words, to express the above need, the end user could set:

  • >=1.0.0 <2.0.0
  • 1.x.x or 1.*.* or event lighter : 1.x, or 1
  • ^1.0.0

More info on node-semver

And the code looks like:

from semver import max_satisfying

versions = ['1.2.3', '1.2.4', '1.2.5', '1.2.6', '2.0.1']
range_ = '^1.0.0'
assert max_satisfying(versions, range_) == '1.2.6'

So I'd definitely recommend node-semver. Easier for everyone!

@ivankravets

This comment has been minimized.

Show comment
Hide comment
@ivankravets

ivankravets Jan 3, 2016

Member

I got you. I mean that I'm not ready to use package which was updated "2014-06-01". Need to contact with @podhmo and ask him will he support it in future.

python-semver by @k-bx looks as active project.

Member

ivankravets commented Jan 3, 2016

I got you. I mean that I'm not ready to use package which was updated "2014-06-01". Need to contact with @podhmo and ask him will he support it in future.

python-semver by @k-bx looks as active project.

@k-bx

This comment has been minimized.

Show comment
Hide comment
@k-bx

k-bx Jan 3, 2016

if you want >=1.0.0 && < 2 you just do:

>>> import semver
>>> ver = "3.2.1"
>>> semver.match(ver, ">=1.0.0") and semver.match(ver, "<2.0.0")
False
>>> ver = "1.2.3"
>>> semver.match(ver, ">=1.0.0") and semver.match(ver, "<2.0.0")
True

k-bx commented Jan 3, 2016

if you want >=1.0.0 && < 2 you just do:

>>> import semver
>>> ver = "3.2.1"
>>> semver.match(ver, ">=1.0.0") and semver.match(ver, "<2.0.0")
False
>>> ver = "1.2.3"
>>> semver.match(ver, ">=1.0.0") and semver.match(ver, "<2.0.0")
True
@ivankravets

This comment has been minimized.

Show comment
Hide comment
@ivankravets

ivankravets Jan 3, 2016

Member

@k-bx, looks like people like node-semver semantic. I use both of them: generic "semver" for Python-based projects and "node-semver" for Web-projects. "node-semver" is more shorter, but requires knowledges to understand "what does it mean?". As result, generic "semver" is more clear but requires additional condition. >=1.0.0 <2.0.0 vs ^1.0.0.

Proceed from that, I prefer to use generic semver. PlatformIO community consists from different people beginning from students who are not familiar with semver at whole and ending with different developers (C, JAVA, Python, Web, etc.)/system administrators.

@marvinroger do you have any objections?

Member

ivankravets commented Jan 3, 2016

@k-bx, looks like people like node-semver semantic. I use both of them: generic "semver" for Python-based projects and "node-semver" for Web-projects. "node-semver" is more shorter, but requires knowledges to understand "what does it mean?". As result, generic "semver" is more clear but requires additional condition. >=1.0.0 <2.0.0 vs ^1.0.0.

Proceed from that, I prefer to use generic semver. PlatformIO community consists from different people beginning from students who are not familiar with semver at whole and ending with different developers (C, JAVA, Python, Web, etc.)/system administrators.

@marvinroger do you have any objections?

@marvinroger

This comment has been minimized.

Show comment
Hide comment
@marvinroger

marvinroger Jan 3, 2016

To be honest, I am a JS guy so my opinion might be a bit biased here.
You raise two points:

"node-semver" is more shorter, but requires knowledges to understand "what does it mean?"

I have to say that >=1.0.0 <2.0.0 also works with node-semver, so beginners won't have any problem either way. But more advanced users could benefit from the other more advanced specifiers.

I'm not ready to use package which was updated "2014-06-01"

I can't disagree with you on that point. But, the goal of node-semver is rather straightforward, and once the thing works, it works, and with such a simple goal I don't see what he can enhance on the lib. Moreover, node-semver has an extensive collection of tests, so I would not worry too much about it. The only problem might be maintenance, with a breaking Python change (like Python 2 -> 3, I heard it was kind of a mess).

Anyway, you can't really go wrong on that one, it's no big deal. Having to type >=1.0.0 <2.0.0 instead of 1.x.x is not so bad, but implementing semver will be harder.

@k-bx no offense, both packages are great, but as I said I am a JS guy and I like the way npm handle dependencies in package.json. 😉

marvinroger commented Jan 3, 2016

To be honest, I am a JS guy so my opinion might be a bit biased here.
You raise two points:

"node-semver" is more shorter, but requires knowledges to understand "what does it mean?"

I have to say that >=1.0.0 <2.0.0 also works with node-semver, so beginners won't have any problem either way. But more advanced users could benefit from the other more advanced specifiers.

I'm not ready to use package which was updated "2014-06-01"

I can't disagree with you on that point. But, the goal of node-semver is rather straightforward, and once the thing works, it works, and with such a simple goal I don't see what he can enhance on the lib. Moreover, node-semver has an extensive collection of tests, so I would not worry too much about it. The only problem might be maintenance, with a breaking Python change (like Python 2 -> 3, I heard it was kind of a mess).

Anyway, you can't really go wrong on that one, it's no big deal. Having to type >=1.0.0 <2.0.0 instead of 1.x.x is not so bad, but implementing semver will be harder.

@k-bx no offense, both packages are great, but as I said I am a JS guy and I like the way npm handle dependencies in package.json. 😉

@k-bx

This comment has been minimized.

Show comment
Hide comment
@k-bx

k-bx Jan 3, 2016

Oh no problem at all! Even more, I don't mind adding node's syntax to my package in future, so PRs are welcome in case if that node-semver package will be abandoned.

k-bx commented Jan 3, 2016

Oh no problem at all! Even more, I don't mind adding node's syntax to my package in future, so PRs are welcome in case if that node-semver package will be abandoned.

ivankravets added a commit that referenced this issue Sep 9, 2016

Merge branch 'develop' into feature/unicode-issue-771
* develop:
  Fix incorrect line order when converting from INO to CPP and pointer is used
  Fix unit test
  Notify about `version` field when creating library
  Add support for SparkFun Blynk Board
  Return valid exit code from ``plaformio test`` command
  Disable SSL Server-Name-Indication for Python < 2.7.9
  Version bump to 3.0.1 (issue #772)
  Disable temporary SSL for PlatformIO services // Resolve #772
  Version bump to 3.0.0 (issues #770, #766, #747, #730, #765, #640, #659, #742, #459, #542, #763, #759, #753, #757, #749, #748, #745, #519, #709, #743, #413, #498, #410, #740, #361, #414, #554, #732, #588, #475, #461, #101, #719, #721, #537, #415, #522, #289, #556, #570, #456, #617, #432, #408, #479, #667, #510)
  Fix menu height for  docs
  Fix issue with multiple archives when linking firmware
  Add migration guide for PIO2 to PIO3
  Search libraries by headers/includes with ``platformio lib search --header`` option
  Update pio run command examples
  Add Unit Testing Demo
  Update PIO Plus badge title and link
  Add PlatformIO Plus badge
  Add links to PlatformIO Plus
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment