Repository navigation
♻️ Release Automation #7271
Description
New Feature / Enhancement Checklist
- I am not disclosing a vulnerability.
- I am not just asking a question.
- I have searched through existing issues.
TLDR
The goal is to have predictable, frequent, immediate, up-to-date releases of Parse Server with a high degree of automation by mid / end of 2021.
Current Limitation
Parse Server has no fixed release cycles.
Feature / Enhancement Description
Introduce a fixed release cycle which helps developers, contributors and repo managers to better plan.
This requires the introduction of a versioning system. Ideally, we go with semver:
- Breaking change, significant feature additions, UI redesign be a major increment.
- Feature additions be a minor increment.
- Bug fixes be a patch increment.
A simple release cycle, for example:
- A major release every 6 months (to make breaking changes that have been announced in at least the previous major release).
- A minor release every month (to release new features, improvements)
- A patch release every month (may be merged with the minor release) or immediately if the fix is at least a bug of severity S2
I expect that in the process we can automate some of the release tasks, so that it becomes less work to actually do a release and we can drive down the times between minor and patch releases.
Long Term Support (LTS)
LTS means that certain versions do not receive breaking changes but only bug fixes or minor compatibility changes that are not breaking. Once a version goes into LTS, a developer can update to newer patched versions without having to worry about significant or breaking changes, while knowing that the LTS version keeps receiving the latest security fixes. It basically decouples feature changes from security fixes.
Maintaining multiple LTS versions significantly increases resource requirements and may therefore require more extensive considerations. To follow a step-by-step approach it makes sense to keep LTS out of scope for this discussion. Since LTS depends on release cycles, I suggest to first finish this issue with a satisfying level of automation and based on that experience, open the LTS discussion with more insight at a later stage.
Related issues:
Roadmap
- Introduce bug severity levels to classify severe bug fix for patch release 💬 Update of issue labels #6984
- Add changelog entry with every PR to reduce release effort Improve issue templates & add PR template #7051
- Introduce versioning system docs: add versioning system to contribution guide #7294
- Introduce centralized deprecation mechanism Add centralized deprecation #7302
- Introduce deprecation policy Add Phased Deprecation Policy #7198
- Introduce bot to enforce PR syntax compliance Add issue bot to assist contributors #7522
- Add conventional commit docs and bot enforcement docs: add angular commit #7567
- Inform contributors of open PRs to merge before
5.0-beta - Introduce new branch system ⚠️
masterbranch is nowalpha#7639 - Automate release process to reduce effort from ~30-60mins to <5 mins
- Experiment with Long-Term-Support --> ongoing with LTS for 4.x releases
- Feature freeze
5.0-betaand fix any bugs before stable release - Introduce release cycle policy docs: add versioning system to contribution guide #7294
- Release
5.0as "fresh start" (beginning 2022) build: release 5.0 #7851 - Advertise new release cycle to community to get more deployments onto the release train
See parse-community/parse-dashboard#1813 as a detailed example for how to implement release automation in an existing repository.
Activity
sadortun commentedon Mar 16, 2021
Hi guys!
As a "user" We are using Parse Server on many different projects, I think there is a few important things that should be taken care of. As mentioned previously, update fatigue is something to consider.
When making your decision on a standardized release cycle, I have a few things :
Whatever the new version is, it's super important to know if this major/minor release will be supported and for how long. I would never update a project to the next major if I am not sure for how long it will be supported with patches.
Current
v4.5.xshould be a LTS. Users who don't want to receive breaking changes should be able to continue on this and continue to receive bugfixes and security fixes for 1+ year.There should be at lease one LTS per Major. For at least the current and last Major.
Having at least patch release per month is a must. If your release process is not too consuming, maybe every 2-3 weeks :)
Minor releases every 2-4 months.
For major releases, I'm not sure if it make sense to have a release schedule since this project is based in community contribution. That said, it would be really great in the readme to have a section about the Upcoming Major detailing a roadmap, expected deprecations and expected release.
Have a nice day!
mtrezza commentedon Mar 17, 2021
Here is a pro / con list as basis for discussion:
Phased Deprecation
Pros:
directAccess,singleSchemaCache,PagesRouter. For example, for thePagesRouterI already added a TODO list to the PR for what needs to be changed to move it out of experimental status, so it will easy to pick this up again in a few months. There is not much difference in work volume, had I done it immediately.Cons:
Versioning System (semver)
Pros:
Cons:
Release Cycles
Pros:
npm outdatedto be made aware that there is a new release; now these tools falsely report that they are on the latest and greatest version of Parse Server, which cannot be true when the last release was 4 months ago and there are many improvements queued in the master branchCons:
General Note
Most important for all of the above is that they mitigate upgrade fatigue, because developers don't have to worry doing a patch or minor version upgrade. Which means developers are more likely to upgrade to newer versions, ergo we get more feedback more quickly for more recent versions of Parse Server, which speeds up
We currently block our own gears. We have 2-4 months between releases, presumably the majority of developers is not deploying the master branch, and if, most likely not in production, that creates a feedback lag of presumably half a year(!).
sadortun commentedon Mar 17, 2021
How much time does it take you to make a release ?
mtrezza commentedon Mar 17, 2021
@davimacedo How long did it usually take to make a Parse Server release?
I think the key is to maintain it constantly and require less ad-hoc effort on release. We are already doing that for Parse Server because the changelog is now always up-to-date as it is a requirement since we switched to the new PR template half a year ago. There should be virtually no effort anymore other than a superficial changelog review.
davimacedo commentedon Mar 17, 2021
It is not that much work. Let's say 30 min. Now that we are adding the entries to the changelog in each PR, it should be faster. It is more time consuming when we have relevant changes in the dependencies and we need to release everything bottom up. I'd love to migrate the project to a monorepo with all js projects.
mtrezza commentedon Mar 17, 2021
My expectation is that this should not take longer than 5 minutes (+5 min effort for one reviewer) even without any more sophisticated automation. A release should be exclusively a meta review, without having to review or touch any actual code.
@davimacedo If it's fine with you, I'll do the next release with your guidance, this or next week and we'll document any bottlenecks and see what we have to address to get to the 5 mins. And we'll do the versioning already according to semver to finally get this ball rolling.
davimacedo commentedon Mar 17, 2021
Sure. We can do that.
mtrezza commentedon Mar 22, 2021
Here is a practical example of how to do a breaking change going forward.
sadortun commentedon Mar 22, 2021
@mtrezza in this case, what can be done would be to imement the PR now, but add a config parameter that would default to
falseIf the parameters remind
undefinedyou display a deprecation warning to the logs untilv5.0.0, after that you change the default behaviour.Since youre also considering refactoring the server config, I would recommend implementing support for the new structure in current
v4.xwith a mention that previous structure will be deprecated later.Deprecations are just fine if:
v5.0or looking at a CHANGELOG.For example, WordPress is dooing an awesome job at this!
mtrezza commentedon Mar 22, 2021
@sadortun How does this differ from the suggestion made in #7292 (comment)?
The current plan is to constantly allow the addition of deprecation warnings, then a release has to happen to make these warnings visible to everyone who upgrades. Then these warnings are displayed during one full major release cycle, I'm currently estimating 6 months or 12 months. Developers have (half) a year time to adapt their deployments. Then, on the next major release, the breaking changes are actually coming into effect. That guarantees that deprecation warnings are displayed during at least one major release.
Good point, there is a PR in the works to centralize deprecation warnings. A contributor can easily see which parts of the code are deprecated by looking into the deprecation definitions.
mtrezza commentedon Mar 23, 2021
For future discussion about release automation, we may use something like https://github.com/semantic-release/semantic-release. That would also define the branch structure to use. Still requires to compare the different auto-release approaches available.
sadortun commentedon Mar 24, 2021
mtrezza commentedon Mar 24, 2021
sadortun commentedon Mar 24, 2021
11 remaining items
Moumouls commentedon Apr 9, 2021
mtrezza commentedon Apr 9, 2021
Moumouls commentedon Apr 9, 2021
azlekov commentedon May 14, 2021
mtrezza commentedon May 14, 2021
sadortun commentedon Jun 8, 2021
Hi guys, quick somewhat related question!
Would you be able to use GitHub
Projects/Milestonesand tag the targeted versions for issues/PRs to be implemented? This would help us (the users) to have a better idea of what is comming in future releases, and also have an idea of the progression of each future releases.mtrezza commentedon Jun 9, 2021
@sadortun The majority of code changes currently come from voluntary contributors. Because they are voluntary, adherence to a timeline cannot be expected. The PMC is currently working on a forward looking project management approach (compared to the current reactive approach) that should bring more implicit predictability in general for developers. Which tools are most practical (GH Milestones, etc) will be determined in the process.
mtrezza commentedon Jun 23, 2021
The question pops up at times, so here is the status for the next major release:
#7492
[-]♻️ Fixed Release Cycles[/-][+]♻️ Release Automation[/+]parse-github-assistant commentedon Oct 13, 2021
Thanks for opening this issue!
mtrezza commentedon Mar 24, 2022
Closing this finally.