[Jenkins-infra] [INFRA-910] Automating release of Jenkins

Olblak me at olblak.com
Fri Jul 27 19:54:42 UTC 2018

> Note there is no "promotion" involved. The master branch and stable-*> has independent releases, both maven and native ones. (Do not let the> fact that sometimes .1 has no backports in it (and is practically
> identical to the baseline) confuse you.)

Does it mean that master correspond to weekly and stable-* to lts
Does the branch name format have a meaning?

Does it make sense to use the branch name to define the kind of release?If the branch is <mavenProfile>-<version>, mvn command would be " mvn -P
<mavenProfile> -Dtag=<version> release:prepare
I noticed that maven increment the version when mvn release:perform is
called, how does that works if:You run mvn release:perform from master current version 2.132 and then
you create a branch stable-2.13X and run release:perform from there.Is the version be incremented two times? 2.132 and then 2.133

> LTS releases has never had native bits build for RCs so I guess
> this can> go too unless we want to start distributing there after your
> improvements are implemented. The reason we did not do it was the lack> of automation of the release process which is a problem about to
> go away.
It a personnal opinion but I don't see the benefit to have 4 different
releases, weekly and lts are I think enough.And once automated build are ready, weekly could become 'daily' if there
is a need for it.
> Would it make sense to merge IEPs into JEPs?
> Inftrastructure is a critical part of the project, and it would be
> great to have it in the same place as other enhancement proposals
IEP was there first :D but indeed the idea is the same and It could
bring more visibility on the infrastructure so I am not against it.

-> gpg --keyserver keys.gnupg.net --recv-key 52210D3D

On Fri, Jul 27, 2018, at 6:51 PM, Kohsuke Kawaguchi wrote:
> This is really exciting. It'd be a big day when this goes LIVE!!!
> On Tue, Jun 5, 2018 at 8:01 AM Olblak <me at olblak.com> wrote:
>> Hello, 
>>  I started to have a look to the release automation epic (INFRA-910)
>>  and I am looking for feedback from people involved with the package
>>  release process to understand how it works and what would be the
>>  needs in a new process.>> 
>>  The way I understand this epic, involves several sub parts.
>>  1. Release Packages
>>  This would be building, signing, publishing all jenkins packages
>>  from trusted.ci>> 
>>  As far as I understand it , we should adapt this script from Kohsuke
>>  https://git.io/vhBZN, in a new Jenkinsfile.release file on
>>  jenkinsci/jenkins repository. And it would be manually triggered
>>  from trusted.ci.>>  I still have to write an IEP document about this.
>>  2. Distribute Packages
>>  This part is about how we provide packages to end users.
>>  This would include War, Windows, Mac OSX, Debian, Redhat and
>>  Opensuse packages>>  I started working on a draft here https://git.io/vhBGl .
>>  3. Update Center
>>  This draft proposes an update on the 'update center' service.
>> https://git.io/vhBGO
>>  Am I missing a big element? 
>>  Cheers,
>>  _______________________________________________
>>  Jenkins-infra mailing list
>> Jenkins-infra at lists.jenkins-ci.org
>> http://lists.jenkins-ci.org/mailman/listinfo/jenkins-infra
> -- 
> Kohsuke Kawaguchi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jenkins-ci.org/pipermail/jenkins-infra/attachments/20180727/7bea9609/attachment-0001.html>

More information about the Jenkins-infra mailing list