The main aim of this doc is to gather outlines and rules, that should followed when back-porting to the LTS. The main idea is that based on following rules the process (or some part of the process) could be scripted and automated.
General rules
- All important bug-fixes should have JIRA
- Git commit should contain a reference to appropriate JIRA so that link to the commit is present in the comment in JIRA or it can be easily found in git log
- Whoever commits a fix for a given JIRA will close the JIRA (question: how to verify, that it really fix the issue?) and eventually fix the JIRA priority
Back-porting
- Back-port all blockers and critical issues which were fixed and are already in Jenkins release for 14 days (appropriate JIRA is not re-opened)
- Question: How to deal with/automate fixes containing several commit during loner time period?
- No new features from upstream are back-ported
Releases
- Major release every 3 months
- Minor release "when needed", i.e. when some blocker or critical bug is fixed and is in Mainline release is verified that it's really fixed.
Example LTS release schedule
Date |
Mainline Release |
LTS Release |
|---|---|---|
2011-07-11 |
1.420 |
1.409.1 |
2011-07-18 |
1.421 |
1.409.1 |
2011-07-25 |
1.422 - fixed major bug JENKINS-10000 |
1.409.1 |
2011-08-01 |
1.423 |
1.409.1 |
2011-08-08 |
1.424 |
1.409.1 |
2011-08-15 |
1.425 |
1.409.2 - fixed major bug JENKINS-10000 |
2011-08-22 |
1.426 |
1.409.2 |
2011-08-29 |
1.427 - fixed major bug JENKINS-10345 |
1.409.2 |
2011-09-05 |
1.428 - refix major bug JENKINS-10345 |
1.409.2 |
2011-09-12 |
1.429 |
1.409.2 |
2011-09-19 |
1.430 |
1.409.2 |
2011-09-26 |
1.431 |
1.409.3 - fixed major bug JENKINS-10345 |
2011-10-03 |
1.432 |
1.409.3 |
2011-10-10 |
1.433 |
1.424.1 - includes fix for major bug JENKINS-10345 |
Testing
- CI
- Manual tests (how will do the test, how to coordinate and share the results?)
- Plug-in and their compatibility with RC (how to coordinate and share the results?)
- How to share experiences from your instances (e.g. I staged latest LTS RC in our environment and run into the following troubles)?
Nice to have
Following points don't seems to be easily implemented in near future, but it would be nice to have them one day :-)
- Every blocker and critical JIRA issue should have target release (hard to decide, which version it should be, if the patch is not available yet)
- Every commit which fixes blocker or critical issue should have a test which verifies it
- Fixed all JIRAs targeted to this release
- No release until all blockers are fixed (this would suppose that we will review the existing blockers first and eventually change the priority)