Skip to end of metadata
Go to start of metadata

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)
  • No labels