4 ms·
Not bad, we might steal some of these ideas for build2 if you don't mind. > other community members should be allowed to apply to take over that name. Of cours
by boris 6y ago
Not bad, we might steal some of these ideas for build2 if you don't mind.
> other community members should be allowed to apply to take over that name. Of course, existing releases would stay untouched, but if I stopped maintaining my JSON library at 1.3.7, someone else should be allowed to take that over and publish 1.3.8 or later.
This part is iffy: if you release a patch, it implies that it has backwards-compatible interface. So this will realistically only work for taking over the maintenance of the old package, not for replacing it with something entirely new. I think a version epoch might work for the latter.
- majewsky 6y agoThat's something the curators would have to look out for. If you're building a green-field solution, I'd also suggest to outright reject library versions that don't follow semantic versioning. A patch version bump that changes the API? Not allowed, go bump your minor version and come back. A minor version that breaks existing users? Not allowed either. It's a really easy check. I'm honestly baffled no one's doing it yet. (Side-note: I'm only talking about libraries here, not applications.)