mirror of
https://github.com/semver/semver.git
synced 2026-07-11 04:52:47 -05:00
[GH-ISSUE #717] Is SemVer abandoned? #3203
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#3203
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @adamralph on GitHub (Jun 26, 2021).
Original GitHub issue: https://github.com/semver/semver/issues/717
I can't find any maintainer activity in at least six months even though several issues and PR's have been opened and discussed.
@krader1961 commented on GitHub (Jun 28, 2021):
Certainly the concept of semantic versioning is not dead. And this specification is still useful and used by many projects. Nonetheless, I share your concern since there are 16 pull requests (proposed changes) older than a year as I type this. That is not acceptable. A proposed change should be merged or rejected in a timely manner. Even for an open source project a year or more does not meet that standard.
P.S., The only reason I'm commenting is because I just opened issue #718 which resulted in my looking at the open issues and pull-requests. I'm dismayed by what I saw given that this is otherwise a great initiative.
@bl-ue commented on GitHub (Jun 29, 2021):
Pinging maintainers @alexandrtovmach @anangaur @dherman @indirect @isaacs @segiddins @Seldaek @steveklabnik
@alexandrtovmach commented on GitHub (Jun 29, 2021):
What kind of activities do you expect?
From contribution guide:
I'm not saying that there a lot of maintainers activity, but I don't see anything that requires it.
SemVer it's static specification, which not going to update every month, and I'm handling things about typos/translations.
In addition, you can check this issue to get more details about RFC process.
@alexandrtovmach commented on GitHub (Jun 29, 2021):
@alexandrtovmach commented on GitHub (Jun 29, 2021):
@krader1961 About resolving old issues/PRs yeah, maybe I'm not so active, but I'm trying to put some time on it per week. In your specific case, you received answer from @ljharb in the same day as you create a ticket.
Summary: SemVer is not abandoned, at least I haven't this feeling
@krader1961 commented on GitHub (Jun 29, 2021):
@alexandrtovmach, The comment by @ljharb was appreciated but did not answer my question and he's not a maintainer able to accept (or reject) pull requests.
@alexandrtovmach commented on GitHub (Jun 29, 2021):
He's one of the most knowledged and active persons in this project, so his answers very useful and clear
@alexandrtovmach commented on GitHub (Jun 29, 2021):
I can accept/reject PRs with typo/translations changes, but not something that change meaning of the spec.
@adamralph commented on GitHub (Jun 30, 2021):
@alexandrtovmach for example: merging/rejecting PR's, responding to questions, acknowledging issues.
I'm not sure how this is relevant. I'm not making any references to RFC's specifically. I'm making references to any type of activity since I'm seeing none.
As above, merging/rejecting PR's, responding to questions, acknowledging issues, etc. I'm not seeing any of this. For example, I raised this PR almost 9 months ago and there has been no reaction of any sort from the maintainers. I would have expected the PR to have either been merged or rejected by now.
I'm not expecting an update to the specification every month, but I think it's not unreasonable to expect a reaction from the maintainers on a PR that has been open for 9 months.
That's good to know, but as I say, I haven't seen any activity from the maintainers for many months. Perhaps there have been no typo/translation issues/PRs raised in that time. Note that:
Again, I'm not sure how this is relevant. I'm not making any references to RFC's specifically. I'm making references to any type of activity since I'm seeing none.
The screenshots you posted show some activity in another repo, https://github.com/semver/semver.org, but I'm not sure they show any evidence of maintainer activity in this repo, https://github.com/semver/semver, and as I say, there have been plenty of issues and PRs raised in this repo with no maintainer reaction for several months.
As pointed out by @krader1961, @ljharb is not listed as a maintainer.
Are you able to also accept/reject PRs such as this?
Again, it's good to know that you can address typo/translation PRs, but it doesn't change the fact that there has been no maintainer activity in this repo for many months with respect to merging/rejecting any kind of PR, responding to questions, acknowledging issues, etc.
Circling back to the intent of this issue — I guess what I'd like to see here is a concerted response from the listed maintainers that the repo is either abandoned, or not abandoned. A lack of response can, again, only be interpreted as saying that the repo has been abandoned.
@alexandrtovmach your responses are appreciated, but I say, you are not listed as a maintainer, and you have only so far expressed "a feeling" that the repo is not abandoned, so I feel unable to recognise that as an indicator.
Once we know whether the repo has or has not been abandoned, we can take appropriate action, such as recomposing the group of maintainers, helping the maintainers to get things moving again, forking a replacement standard, etc.
@segiddins commented on GitHub (Jun 30, 2021):
The repo has not been abandoned, but please keep in mind that each of the listed maintainers is a volunteer representing a separate packaging ecosystem--no one is working on semver full time, but rather our goal is to continue to coalesce around how semver is used in practice, as implemented
@adamralph commented on GitHub (Jun 30, 2021):
Thanks @segiddins. I do appreciate that you are volunteers and not working on SemVer full time.
But the fact that your comment is the first I've seen from any of the maintainers in at least six months, given that several issues and PR's have been opened and discussed during that time, does suggest that something is missing. Is there anything that I or anyone else can do to improve that situation? For example, I'd find it quite easy to review and merge https://github.com/semver/semver/pull/660/files
@krader1961 commented on GitHub (Jul 1, 2021):
@segiddins, I opened issue #718. Normally I would go ahead and create a pull-request to solve the issue myself. But since there are 22 open pull-requests, most older than a year and two are eight years old, I can't see the point of doing the necessary work. Only one PR (#619 which was rejected) has been handled in the past year.
@alexandrtovmach, You've said that you try to handle wording clarification changes. Yet PR #660 has been open for four months and changes a single word. Note that personally I think the singular "version" is fine in that context and that PR should be rejected, but then I'm not an english teacher.
Maybe start by simply closing (rejecting) every PR that is older than one year. If it hasn't been merged by now it seems unlikely to be merged and/or is probably obsolete.
@steveklabnik commented on GitHub (Jul 6, 2021):
Speaking only for myself, I have had an intense amount of other open source and life commitments lately, and so have not had a ton of time for SemVer specifically. I also think that is okay; as something that is widely used by a large number of ecosystems, moving slowly is a good thing, not a bad thing.
@alexandrtovmach commented on GitHub (Jul 7, 2021):
@krader1961 @adamralph will try to go over PRs this weekend
@krader1961 commented on GitHub (Jul 7, 2021):
@alexandrtovmach, Thank you. I agree with @steveklabnik that changes to this project should be conservative. That is, slow to adopt changes. Nonetheless, there is a big difference between "moving slowly" and "moving glacially". Pull requests open more than a year should be closed. Either by requesting more discussion in an associated issue or explaining why the proposed change is inappropriate. If there isn't an issue associated with the pull-request that, itself, is a red flag the proposed change should be rejected without further consideration unless it is a trivial "typographical/wording" fix.
@adamralph commented on GitHub (Jul 7, 2021):
Changing the spec and responding to issues and PR's are different things. I agree that changes to the spec should generally be slow. Responding to issues and PR's does not have to be. A response may be: accepting a minor typo/wording fix, rejecting an issue or PR, or just acknowledging one, even if it requires more effort which can only be spent later.
Radio silence communicates abandonment. The lack of response from the listed maintainers to anything raised in this repo in at least six months prompted me to ask if it was abandoned. Apparently it is not abandoned and it seems the ball may be rolling now; we have responses from two listed maintainers in this issue. 🎉
I don't want point out problems without offering something, and that's why I've offered my time to help.
I believe this issue has served its purpose now, so I'm closing it.
BTW — I started this discussion as an issue because discussions are not enabled for this repo. Perhaps that's something the maintainers may want to consider enabling.
Thank you to everyone who chimed in.
@steveklabnik commented on GitHub (Jul 7, 2021):
Yes, the balance is tricky, for sure. I appreciate you bringing it up. Spec work can feel very different than general open source development, and so expectations can be hard to manage for anyone involved.
I do like the idea of having discussions open here; to be honest a lot of the open issues are more discussion-like than actual spec work, and it's possible that properly enforcing that split would help quite a bit.