Add version tags to micropython-lib to match the micropython repo

Josverl commented 2 years ago

In the interest of being able to build a version of micropython that is not the latest, this requires both the micropython and micropython-lib to be checked out.

they should be checked out to the same state/date for that target version of micropython

for the micropython repo this is simple, just check out the tag
- see: https://github.com/micropython/micropython/tags
for the micropython repo this is more complex , as only a few tags added to the repo ( last one on 2017)
- Only a few tags are present : https://github.com/micropython/micropython-lib/tags
- in order to work around this I currently have to
  - get the date/time of the micropython-tag
  - find the last commit before that date-time in the micropython-lib repo
  - check out that commit-id

The reason I want to be able to build older versions of micropython is to be able to create stubs that can be used for static-type-checking.
Over time the code to generate and fine-tune these stubs evolves, and it would be a waste to only do that for the latest and greatest (unstable) version. rather I want to be able to generate stubs for the last few minor versions of MicroPython.

As my git-fu is limited, in practice I found it simpler to just create a simple lookup-list in a csv instead.

It would be appreciated if the current and future MicroPython's version tags were also applied to the Micropython-lib repo. I would gladly submit a PR , but AFAIK tags cannot be part of a CR

I can offer the CSV I'm currently using,

version,            mpy_date,      lib_date,      lib_commit_hash,                            lib_commit_info
"refs/tags/v1.9.3", "Nov  1 2017", "Nov 1, 2017", "2829d4adc968a7208d96fa762a9ab4c1b744f73d", "threading: Release 0.1"
"refs/tags/v1.9.4", "May 11 2018", "May 11 2018", "f20d89c6aad9443a696561ca2a01f7ef0c8fb302", "logging: Release 0.3"
"refs/tags/v1.10",  "Jan 26 2019", "May 11 2018", "f20d89c6aad9443a696561ca2a01f7ef0c8fb302", "logging: Release 0.3"
"refs/tags/v1.11",  "May 29 2019", "Feb 25 2019", "b89114c8345e15d360c3707493450805c114bc8c", "Revert README: Add note that repository is unmaintained."
"refs/tags/v1.12",  "Dec 20 2019", "Feb 25 2019", "b89114c8345e15d360c3707493450805c114bc8c", "Revert README: Add note that repository is unmaintained."
"refs/tags/v1.13",  "Sep  2 2020", "Jul  8 2020", "7b1161dd1b07e870f09b75a4befc84a95d93e3b3", "logging: Add support for custom handlers"
"refs/tags/v1.14",  "Feb  3 2021", "Sep  3 2020", "eae01bd4e4cd1b22d9ccfedbd6bf9d879f64d9bd", "logging: Add levelno entry to log record object/dict. …"
"refs/tags/v1.15",  "Apr 19 2021", "Sep  3 2020", "eae01bd4e4cd1b22d9ccfedbd6bf9d879f64d9bd", "logging: Add levelno entry to log record object/dict. …"
"refs/tags/v1.16",  "Jun 18 2021", "Jul 12 2020", "3c383f6d2864a4b39bbe4ceb2ae8f29b519c9afe", "aioble: Fix docs for subscribe (needs await)."
"refs/tags/v1.17",  "Sep  2 2021", "Jul 12 2020", "3c383f6d2864a4b39bbe4ceb2ae8f29b519c9afe", "aioble: Fix docs for subscribe (needs await)."
"refs/tags/v1.18",  "Jan 16 2022", "Nov 11 2021", "cdd260f0792d04a1ded99171b4c7a2582b7856b4",  "aioble/multitests: Add multitest for shutdown handlers."
"refs/tags/v1.19",  "Jun 16 2022", "Jun 16 2022", "db4c739863e49fc874bdaae8aa8c316c7ed4276a",  "unittest: Version 0.9.0"
"refs/tags/v1.19.1","Jun 16 2022", "Jun 16 2022", "db4c739863e49fc874bdaae8aa8c316c7ed4276a",  "unittest: Version 0.9.0"

or in the form of a script

git tag -a v1.9.3  2829d4adc968a7208d96fa762a9ab4c1b744f73d  -m "Micropython v1.9.3"
git tag -a v1.9.4  f20d89c6aad9443a696561ca2a01f7ef0c8fb302 -m "Micropython v1.9.4"
git tag -a v1.10   f20d89c6aad9443a696561ca2a01f7ef0c8fb302 -m "Micropython v1.10"
git tag -a v1.11   b89114c8345e15d360c3707493450805c114bc8c -m "Micropython v1.11"
git tag -a v1.12   b89114c8345e15d360c3707493450805c114bc8c -m "Micropython v1.12"
git tag -a v1.13   7b1161dd1b07e870f09b75a4befc84a95d93e3b3 -m "Micropython v1.13"
git tag -a v1.14   eae01bd4e4cd1b22d9ccfedbd6bf9d879f64d9bd -m "Micropython v1.14"
git tag -a v1.15   eae01bd4e4cd1b22d9ccfedbd6bf9d879f64d9bd -m "Micropython v1.15"
git tag -a v1.16   3c383f6d2864a4b39bbe4ceb2ae8f29b519c9afe -m "Micropython v1.16"
git tag -a v1.17   3c383f6d2864a4b39bbe4ceb2ae8f29b519c9afe -m "Micropython v1.17"
git tag -a v1.18   cdd260f0792d04a1ded99171b4c7a2582b7856b4 -m "Micropython v1.18"
git tag -a v1.19   db4c739863e49fc874bdaae8aa8c316c7ed4276a -m "Micropython v1.19"
git tag -a v1.19.1 db4c739863e49fc874bdaae8aa8c316c7ed4276a -m "Micropython v1.19.1"

stinos commented 2 years ago

Note that recently micropython-lib has been made a submodule of the micropython repository, so theoretically this is now a non-issue and the micropython-lib submodule version which comes with a certain micropython tag should be the correct one for that micropython version.

Josverl commented 2 years ago

@stinos , thanks for pointing that out. at least that should mean that my list should not need to grow longer 🤞 ( and I need to validate my build model for versions >1.19.1)

That still means that practically there is still an issue for people to find the correct version for all published versions even for a submodule I would say the version tags are a simple way of documenting the dependencies between the two

jimmo commented 2 years ago

Thanks @Josverl

I did actually propose this (versioning micropython-lib to the MicroPython release) but it was pointed out that often we want to release libraries on a different interval. I also considered not just versioning the micropython-lib repo but also all of the individual libraries (in their package metadata) to match the MicroPython release. e.g. urequests v1.19.1.x but I'm not sure this makes sense.

As @stinos mentioned our plan going forward is that micropython-lib is now a submodule of the main repo. This is to faciliate the growing number of boards that depend on libraries from micropython-lib. (We're also making this easier via some improvements to the manifest system). So yes, to get the micropython-lib for a given version you can get this from the main repo's submodule.

That said... it might still make sense to tag this repo anyway as part of that process. i.e. the process for making a MicroPython release goes:

tag micropython lib vX.Y
update submodule in main repo to use the new tag
tag main repo vX.Y

In other words, a release tag of main repo has the micropython-lib submodule always pointing to a tagged commit of micropython-lib. That makes sense to me. I think there'll still be situations where we update the submodule between releases though.

And in that case, retrospectively applying the tags that you've listed here wouldn't be an issue. I'll discuss with @dpgeorge and get back to you.

By the way @Josverl -- I have seen your stubs project, it's very impressive. It did strike me that you've done a lot of work and that perhaps if we did a few simple things in MicroPython we could make your life easier. If you want to jump on discord (https://discord.gg/zHgfNMgR) or slack (https://slack-micropython.herokuapp.com) sometime and discuss, we might be able to help you.

stinos commented 2 years ago

That said... it might still make sense to tag this repo anyway as part of that process. i.e. the process for making a MicroPython release goes

That would make a lot of sense indeed

Josverl commented 1 year ago

With the release of v1.20.0 I still see no tags. To avoid any confusion they could be named micropython vX.Y.Z.

For now I've added another line to my matching table

andrewleech commented 1 year ago

The v1.20 tag was added here a few days ago https://github.com/micropython/micropython-lib/tags

dlech commented 1 year ago

Also, since micropython-lib is now a submodule of micropython, going forward, checking out micropython and updating submodules will check out the correct version of micropython-lib.

Josverl commented 1 year ago

Happy to see the V1.20.0 tag.

What works well for a computer interface is often hard to remember and communicate for humans.

micropython / micropython-lib

Add version tags to micropython-lib to match the micropython repo #518