Thank you for the information! As a matter of fact we are using Ubuntu. As part of the upgrade process, I’ve seen Jenkins administrators do the following:
1. Stop Jenkins running as a service. 2. Rename Jenkins current WAR file to jenkins.war.old. 3. Copy the new WAR file into the $JENKINS_HOME directory. 4. Start Jenkins running as a service. 5. Verify Jenkins is working as expected. 6. Remove the jenkins.war.old file from the $JENKINS_HOME directory. I’d like to keep the old WAR file in the directory until we can verify the new WAR works as expected. For this reason, I believe it may not be better to wipe out the original WAR file in $JENKINS_HOME with an apt upgrade. Also, if the Jenkins package is installed from ‘apt’, wont a sudo apt get update / upgrade automatically upgrade my Jenkins instance? Thank you again for your advice! -Jason From: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] On Behalf Of Mark Waite Sent: Monday, July 03, 2017 4:34 PM To: jenkinsci-users@googlegroups.com Subject: Re: Jenkins LTS Release Line: Frequency / Process of Upgrading Jenkins on LTS release schedule That is the technique I've used, though I've preferred to simplify the upgrade process by using either Debian or Ubuntu as the host operating system, then installing Jenkins from the "apt" package manager. That simplifies the "upgrade and copy the war" step. It doesn't really remove any of the other steps. If you're a Red Hat / CentOS type, then you'll use the rpm based distribution for the same benefit. Mark Waite On Mon, Jul 3, 2017 at 2:20 PM Jason LeMauk <jason.lem...@csquaredsystems.com<mailto:jason.lem...@csquaredsystems.com>> wrote: I am currently working to setup a Jenkins server for continuous integration. One area of Jenkins maintenance I am looking at is Jenkins upgrades. As gaining access to new Jenkins features is less important to our setup than receiving important bug fixes and general system stability, I am considering upgrading our Jenkins instance on the LTS release schedule. It should be noted that we are currently working with Jenkins version 2.46.3 and would start this schedule by upgrading to Jenkins version 2.60.1. In looking at the documentation for [Jenkins LTS Release Line][1], it looks like this would involve upgrading our Jenkins from the previous LTS version to the new LTS version every 6 - 9 weeks: > The cycle starts with picking an LTS baseline at week 0. Then, there > is a two week period for backporting followed by two weeks for testing > the release candidate resulting in the release of X.1. Backporting and > RC testing is repeated twice, producing X.2 and X.3. This concludes > the cycle for a given baseline and the new one is started immediately. > > The baseline release is typically between 2-5 weeks old when it is > chosen, so X.1 LTS releases are published about 6-9 weeks after their > baseline. Am I correct in this understanding that if we were to keep up with the LTS release schedule we would be upgrading our Jenkins instance about every 6 - 9 weeks? Also, from what I have seen, if your Jenkins instance is installed via Jenkins WAR file, then the process for upgrading the Jenkins instance to the most recent Jenkins LTS version is: 1. Stop Jenkins running as a service. 2. Back up the Jenkins $HOME_DIRECTORY. 3. Download the latest LTS WAR file. 4. Replace the WAR file currently in $JENKINS_HOME directory with the newest LTS WAR. 5. Start Jenkins running as a service. 6. Upgrade any plugins if necessary. 7. Restart Jenkins as a service if necessary for plugin installation. 7. Work out any Jenkins job issues caused by upgraded plugins. Is there anything here I'm missing as far as getting our Jenkins instance onto the LTS release schedule? Is this generally best practice? Just wanted to get some input and advice from those with experience maintaining a Jenkins instance on the LTS release schedule. [1]: https://jenkins.io/download/lts/ -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com<mailto:jenkinsci-users+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599FFD3DBC9C44D93D0E8C589D60%40BY2PR12MB0599.namprd12.prod.outlook.com<https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599FFD3DBC9C44D93D0E8C589D60%40BY2PR12MB0599.namprd12.prod.outlook.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com<mailto:jenkinsci-users+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGgvhAbFy52wRS3%3DsaSTeDko5VN%2BjMDVo4Hxj%2BjPh6Zhg%40mail.gmail.com<https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGgvhAbFy52wRS3%3DsaSTeDko5VN%2BjMDVo4Hxj%2BjPh6Zhg%40mail.gmail.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599DA08EA206C880190B22189D60%40BY2PR12MB0599.namprd12.prod.outlook.com. For more options, visit https://groups.google.com/d/optout.
