docs: add versioning system to contribution guide #7294
Conversation
Codecov Report
@@ Coverage Diff @@
## alpha #7294 +/- ##
==========================================
- Coverage 93.99% 93.90% -0.10%
==========================================
Files 181 181
Lines 13382 13209 -173
==========================================
- Hits 12579 12404 -175
- Misses 803 805 +2
Continue to review full report at Codecov.
|
Generated by 🚫 dangerJS |
|
@sadortun what do you think about this versioning system? |
|
@davimacedo, @dplewis, @TomWFox May I ask for your review of this? Once we have used and refined this for some time, we would eventually apply this to all Parse Platform repos, I estimate in 2022. This is part of a larger roadmap as described in #7271. |
mtrezza
force-pushed
the
add-versioning-system
branch
from
84d06d1
to
6224efd
Compare
There was a problem hiding this comment.
I must admit, I find this quite difficult to evaluate, so many angles to consider and plenty of unknowns. I do really appreciate your forward thinking.
I'm concerned that doing a release at the beginning of every year may prove challenging. It's important that voluntary contributors contribute when they can & want to. I don't think we should expect team members to put together a major release on a fixed schedule - with changes being required to introduce breaking changes. We won't be able to rely on the original contributor to come back after a year to make the required changes.
If we had a part/full time paid contributor with agreed responsibilities it would be a different story.
I'm not sure I can support this unless you or other contributors are happy to take on the responsibility to put together the major releases.
That's a non-issue. All this says is that we increment the major version with the first release of a year, whenever that is. This is not more or less work.
I think you are overestimating the effort it takes to do a release, and it doesn't have to be Jan 1st. We are going towards release automation and will open a pre-release distribution channel, so making a release should be a 5-10 min effort. We need to step up release frequency anyway, so there will likely need to be a release in Jan or Feb of the year anyway to fix a vulnerability. I read your concern as "we cannot commit to find someone spending hours to do a release every year on Jan 1st". That I would agree with, but that's not part of this policy. It is irrelevant whether we increase the major version every year or not. It's not more or less work. The only benefit this brings is that we set up a versioning system that allows us to experiment with LTS without having to make another adaption to the versioning system. |
Due to the deprecation policy a major release will be more work, I thought we established that when discussing the introduction of the policy? This means that the first release of the year will require more work and unless we want to go months without any releases then it will be required within Jan or feb.
Having done releases before I completely understand the effort. To be clear I wouldn't see an issue with this pre-deprecation policy. I don't have a problem with this policy per se or the deprecation policy per se; it's both together which I see as being incompatible with a relatively small number of voluntary contributors. |
|
My suggestion is: let's aim high and fail fast. We are both guessing estimates for an automated release system that doesn't exist yet. Let's dare to be ambitious and if there is an issue, we can address that specifically and practically. |
|
We can take that approach. With that being the case, I think it would be sensible to add a note to this policy (and in reflection the deprecation policy) that it's aspirational, we don't know if we can adhere to it fully and it's likely to see significant changes as we work out the practicalities. Obviously there are no warranties with this project as set out by the license but I think it would help to set expectations for both people using the project & us contributors 🙂 |
|
I suggest we continue to pursue a non-ambivalent, declared and enforceable policy. If we can't fulfill it, then we adapt it. Adding an aspirational note already puts this into a psychological "likely we can't do it" / "it's not really important" context, which is predestined to lower compliance. This is part of a larger roadmap, and to make sure we reflect on any changes in effort, we can formally establish some review milestones throughout 2021 and 2022, which is during and after the implementation of the new automated release system, how about that? |
|
I disagree with your framing. I believe that such a note would just be honest, it's much more of a "we're aiming to do this but can't be certain". I would much rather have 'lower compliance' than risk loosing a valued contributor or give people who use the project the wrong idea. Really, it's similar to marking a feature as 'experimenal' or in beta. Reviewing the policy would be a good idea but I don't see it as a substitute to being clear & open about its aspirational nature. |
|
Alright, let's add this then. I'm fine with adding a note that it's a new policy that we're trying out, and once we see that we can reliably fulfill it, we can remove that note. We should be careful about the wording though to be able to reference the policy in reviews. Do you have a suggestion? |
Just an idea: We are commited to respect this release cycle and deadlines to the best of our abilities. That said, this project is supported[sponsors url] by the community and some delays may be possible. If you're interested in helping us, please consider [donation link]. |
Maybe that part could do. I'm not sure which deadlines are meant specifically, I don't think there are any, so maybe leave that out. Donation seems off-topic in this matter and lacking causality, nor have we identified any issues so far. Asking for help to solve an issue that doesn't exist doesn't make much sense. @TomWFox are you ok with this line? |
mtrezza
force-pushed
the
add-versioning-system
branch
from
36bb09e
to
32b8274
Compare
|
@TomWFox I tried to add a note, but I don't want to taint the whole versioning chapter as "aspirational", including basic aspects like committing to semver. Do you have a suggestion about what part of the versioning system specifically you think we may not be able to achieve? |
I think that almost sends the opposite message that I was thinking of. To me it comes across as more of a reinforcement. How about this... "Please be aware that whilst we endeavour to respect this release cycle, it is aspirational. As a project powered by voluntary contributions we may not always be able to, or indeed want to, adhere to all aspects of the policy."
It really comes down to this line...
So perhaps add a note above or below this? |
|
Converted to draft, because the exact versioning system, release labels and release cycles will be mostly determined according to the technical capabilities of the automated release framework. |
|
mtrezza
changed the title
Thanks for opening this pull request!
|
|
🎉 This change has been released in version 5.0.0-alpha.5 |
|
🎉 This change has been released in version 5.0.0-beta.1 |
|
🎉 This change has been released in version 5.0.0 |
New Pull Request Checklist
Issue Description
Parse Server does not declare to follow an official versioning system.
Related issue: #7271
Approach
Declares semver with a flavor of calver as the official versioning system for Parse Server. The goal is to start the next release of Parse Server with
5.0.0using the new versioning system.See the file change:
pre-release-labels; as we get to a more frequent, regular release cycle, we may add release candidates as a "soft" start for new major releases, like 3 months before the end of the year so we can weed out bugs and create a more stable major release (which includes breaking changes).Version numbers are calledmajor,feature,fixto make their purpose more clear and already considers possible branch names, but may well be renamed tomajor,minor,patchas we go along.TODOs before merging
(none)