logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steffen Offermann <steffen.offerm...@aixigo.de>
Subject Re: Release process
Date Tue, 13 Sep 2016 06:38:16 GMT

This is how we do it at our company:

- start a new artifact on branch master, setting the version number in pom.xml to 0.1.0-SNAPSHOT
- create CHANGELOG.md, add a headline "## Last Changes", and during development, add an entry
with a link to the respective JIRA issue for each solved ticket, e.g.
   "- [XYZ-4711](https://.../browse/XYZ-4711): Did this and that."
- to release v0.1.0:
     - run "mvn release:branch -DbranchName=release-0.1.x" (using 0.2.0-SNAPSHOT as the version
number for the next iteration when asked)
     - git checkout release-0.1.x
     - edit CHANGELOG.md (i.e. replace "Last Changes" with "v0.1.0")
     - git add CHANGELOG.md ; git commit -m"Prepared artifact for release of v0.1.0"
     - mvn release:prepare (using 0.1.0 as version number, v0.1.0 as scm tag, and 0.1.1-SNAPSHOT
for the next iteration's version number)
     - mvn release:perform
     - git push -u origin release-0.1.x ; git push -u origin v0.1.0
     - git checkout master
     - edit CHANGELOG.md, adding version information "## v0.1.0"
     - git add CHANGELOG.md ; git commit -m"Prepared artifact for development of v0.2.0" ;
git push -u origin master
- Repeat for each new release

On 09/13/2016 01:39 AM, Matt Sicker wrote:
> It sounds like the idea is to open up a branch for each 2.x release so we can backport
specific bugfixes to the previous release branch to make minor version releases. We could
either fork from the
> last 2.6.x release to maintain a 2.6 branch, or we could start with 2.7.
> If there's an easy way to merge specific code changes to multiple branches, maybe we
could adopt that, but I'm not exactly sure how well that would work in practice unless we
fix that end of line
> problem that keeps popping up in certain commits (the ones that rewrite the whole file).
That would cause annoying merge conflicts between major release branches.
> On 12 September 2016 at 17:50, Remko Popma <remko.popma@gmail.com <mailto:remko.popma@gmail.com>>
>     Back to the discussion about the release process, concretely what are we going to
do differently from what we do now?
>     On Sat, Sep 10, 2016 at 3:26 AM, Gary Gregory <garydgregory@gmail.com <mailto:garydgregory@gmail.com>>
>         Remko has a branch to merge.
>         I'd like to hear from Steffen Offermann <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=SteffenO>
who has been testing master...
>         Gary
>         On Fri, Sep 9, 2016 at 11:13 AM, Matt Sicker <boards@gmail.com <mailto:boards@gmail.com>>
>             Are we all caught up with the desired branches we wanted merged?
>             On 9 September 2016 at 13:08, Remko Popma <remko.popma@gmail.com <mailto:remko.popma@gmail.com>>
>                 What is our thinking on this for the upcoming release?
>                 On Fri, Sep 2, 2016 at 8:22 PM, Mikael Ståldal <mikael.staldal@magine.com
<mailto:mikael.staldal@magine.com>> wrote:
>                     On LOG4J2-1548, Remko Popma <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=remkop%40yahoo.com>
>                         I'm okay with changing the process but we need to think through
the implications of maintaining multiple branches. I don't mind fixing a bug in, say, the
2.7.x maintenance
>                         branch and merging that fix also into the 2.8 new features branch,
but what do we do with subsequent releases?
>                         Once we are on version 2.10, and we receive a bug report against
version 2.7, do we add a fix to the maintenance branches 2.7.x, 2.8.x and 2.9.x in addition
to the 2.10 new
>                         feature branch? When do we stop supporting old maintenance branches?
>                     I think we should make sure that we can always easily make patch
releases on the latest minor release (like 2.6.3 now), and do so whenever a serious bug is
discovered and fixed
>                     (like LOG4J-1548).
>                     I don't think that we should normally make patch releases on older
minor releases (like 2.5.1 now) though. That should only be done in exceptional cases, and
we should not prepare
>                     for it any more than keeping a tag for each release in Git.
>                     I also think that we should consider ways of reducing the number
of serious issues introduced in minor releases, such as making a public beta release before
a minor release. (I was
>                     not really satisfied with the quality of the 2.6 release, and I think
we should try to do better in the future.)
>                     --
>                     MagineTV
>                     *Mikael Ståldal*
>                     Senior software developer
>                     *Magine TV*
>                     mikael.staldal@magine.com <mailto:mikael.staldal@magine.com>
>                     Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>                     Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
>                     (or responsible for delivery of the message to such a person), you
may not copy or deliver this message to anyone. In such case,
>                     you should destroy this message and kindly notify the sender by reply
>             --
>             Matt Sicker <boards@gmail.com <mailto:boards@gmail.com>>
>         --
>         E-Mail: garydgregory@gmail.com <mailto:garydgregory@gmail.com> | ggregory@apache.org
>         Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/>
>         JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>         Spring Batch in Action <http://www.manning.com/templier/>
>         Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>         Home: http://garygregory.com/
>         Tweet! http://twitter.com/GaryGregory
> --
> Matt Sicker <boards@gmail.com <mailto:boards@gmail.com>>

aixigo AG - financial solutions & technology
Karl-Friedrich-Straße 68, 52072 Aachen, Germany
fon: +49 (0)241 559709-65, fax: +49 (0)241 559709-99
eMail: steffen.offermann@aixigo.de, web: http://www.aixigo.de

Amtsgericht Aachen - HRB 8057
Vorstand: Erich Borsch, Christian Friedrich, Tobias Haustein
Vors. des Aufsichtsrates: Prof. Dr. Rüdiger von Nitzsch

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message