When renaming a package, always get a second check from someone else
eeue56 opened this issue · comments
Problem
- elm-lazy-list was renamed to lazy-list
- This was done for 0.18, as we had done similarly for 0.16 -> 0.17
- However, a repo called
elm-lazy-listwas not left behind - As a result, anything in 0.17 that tried to use elm-lazy-list could not find it
- Lazy list is mainly used by elm-test
- This broke all the builds using elm-test for 0.17. All of them.
- This meant that all builds for 0.17 using elm-test were broken for a period of around 3 hours.
Solution
- I saw the rename on my feed, and checked it out as I knew it could be problematic
- I confirmed out builds at NRI were failing from this issue
- I created elm-lazy-list again from pushing a local version of lazy-list up
- I deleted the new 1.0.0 tag and replaced it with the old, 0.17 one. I also pushed up all the tags past 1.0.0, which were still pointing to the 0.16 commits
- This is now fixed
- I've made issues for @mgold to pick up to deal with the remaining tags and documentation
Lessons to learn
- This fire is almost as bad as Node's leftpad issue.
- Please never rename a package without creating a repo with the exact code and tags at the time of renaming.
- Please do not rename packages without running it by someone else first.
- I caught this early because I remembered this from last time when I migrated a bunch of things from 0.16. I should've documented it, as I am now.
Finally
I want to post-face this by saying that this was nobody's fault in particular. If you weren't expecting it, then it's a weird thing to have happen. I double checked this last time during the 0.16 migration, so I also have made this mistake in the past. I'm proud of the work the elm-community maintainers are doing. <3 💯
cc @elm-community/guides @elm-community/manifesto @elm-community/owners @elm-community/packages
Could all maintainers please acknowledge this by giving it a thumbs up or something?
CC people not in the above groups:
@abadi199 @jonboiser @rohanorton @Dandandan @sgraf812 @lorenzo @jaapz
@eeue56 can you add me to one of the groups so I can be notified next time?
We'll make a new group with all registered maintainers in
Thanks
this was nobody's fault in particular
No, this was my fault. I thought that upgrading to 0.18 would be a good opportunity to take care of the rename (which was my idea in the first place, #27). What's funny is that I had initially been hesitant to rename the repo for fear of creating exactly this sort of disaster. But I had done a few of these perhaps six months ago and GitHub and I remember (correctly or not) that it created redirects from the old name to the new. I thought that I could replace the 1.0.0 tag with the 0.18 version and leave the others in pace for 0.17, so there wouldn't be a problem unless someone tried to get 1.0.0 specifically. It was my failure to not check that the redirect had been created. (I also asked GH support to make the repo standalone instead of a fork from NRI; possibly this removed the redirect?) Regardless, I'm sorry for the trouble that this caused.
However, I think the final outcome is quite nice. We have clearly separate repos rather than one repo acting as two through a redirect.
@elm-community/owners - can one of you make me an owner so I can invite more people to the maintainer team?
@eeue56 done!
But I had done a few of these perhaps six months ago and GitHub and I remember (correctly or not) that it created redirects from the old name to the new.
It does create redirects, but not for the zip downloading that Elm uses for grabbing package sources. This was true during 0.16 too - that's where I first came across this issue, when elm-community was taking over the repos owned by circuithub.
I thought that I could replace the 1.0.0 tag with the 0.18 version and leave the others in pace for 0.17, so there wouldn't be a problem unless someone tried to get 1.0.0 specifically.
The reason why this is not okay is because anyone can then do the following:
git clone <repo-with-tags>git checkout 1.0.0- make some changes locally
elm-package bump- Get a new version that matches an existing tag
elm-package publish- Now on package.elm-lang, there will be docs for the 0.18 code they had locally, but it will point to 0.17 code that has a different API
Regardless, I'm sorry for the trouble that this caused.
It's not a problem - luckily it happened when nobody else seemed to be awake, since I saw nobody else spot it during those 3 hours. No issues made on github, nothing on slack, etc. This is why we have elm-community, so we can have each other's backs!
@rtfeldman I think you've added me to the owner group, but not as an owner (so I still can't add people to teams)
Fixed!
Has there been started a discussion at the right place (whatever that is) how we can prevent stuff like this from happening in the future, even by mistake? Like, for example, has there been started a discussion on the elm-package repo how to redesign the package manager in such a way that packages will still be available even if a repo is, say, renamed?
I'm not saying I know what, if anything, should be done at any level, but this seems like a serious flaw in Elm package management. The possible solutions for avoiding this should at least be discussed.
Oh for sure - the plan for awhile has been to focus on elm-package for 0.19, including stuff like this. It's been a known weakness of the implementation since day 1, but other things have taken priority.
There's never been an elm-package unpublish or elm-package rename because it's not intended to be supported. However, the feature of actively preventing those actions hasn't been added yet. 🙂
Good, good. I figured "the right people" had a plan, but it never hurts to make sure :)