From 17ee3ac1cb62d73ec9a796ecd23f19d53b8f3286 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Wed, 9 Jul 2025 03:47:49 +0200 Subject: [PATCH] Release: Introduce the Git-flow branching model Starting with the upcoming ''preview release'', branches, branch names and tags will be rearranged to follow the Git-flow pattern instead of the existing ad-hoc organisation with a release branch. The documentation provided here defines the actual naming conventions and some fine points regarding the version number upgrades and placement of release tags. Furthermore, two helper-scripts are provided to automate version number updates - `buildVersion.py` : extract current version from git tag and allow to bump version - `setVersion` : manipulate all relevant files with `sed` to update the version info --- admin/buildVersion.py | 145 ++++ admin/setVersion | 44 + ...ingGuidelines.txt => CodingGuidelines.txt} | 0 doc/technical/code/GitBranching.txt | 213 +++++ ...kingStructure.txt => LinkingStructure.txt} | 0 doc/technical/code/index.txt | 3 + wiki/thinkPad.ichthyo.mm | 780 +++++++++++++++--- 7 files changed, 1087 insertions(+), 98 deletions(-) create mode 100755 admin/buildVersion.py create mode 100755 admin/setVersion rename doc/technical/code/{codingGuidelines.txt => CodingGuidelines.txt} (100%) create mode 100644 doc/technical/code/GitBranching.txt rename doc/technical/code/{linkingStructure.txt => LinkingStructure.txt} (100%) diff --git a/admin/buildVersion.py b/admin/buildVersion.py new file mode 100755 index 000000000..cf1309cd5 --- /dev/null +++ b/admin/buildVersion.py @@ -0,0 +1,145 @@ +#!/usr/bin/python3 +# coding: utf-8 +## +## buildVersion.py - extract and possibly bump current version from Git +## + +# Copyright (C) +# 2025, Hermann Vosseler +# +# **Lumiera** is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by the +# Free Software Foundation; either version 2 of the License, or (at your +# option) any later version. See the file COPYING for further details. +##################################################################### +''' +Build and possibly bump a current project version spec, +based on the nearest Git tag. +''' + +import re +import os +import sys +import datetime +import argparse +import subprocess + +#------------CONFIGURATION---------------------------- +CMDNAME = os.path.basename(__file__) +TAG_PAT = 'v*.*' +VER_SEP = r'(?:^v?|\.)' +VER_NUM = r'(\w[\w\+]*)' +VER_SUB = r'(?:'+VER_SEP+VER_NUM+')' +VER_SUF = r'(?:~('+VER_NUM+VER_SUB+'?'+'))' +VER_SYNTAX = VER_SUB +VER_SUB+'?' +VER_SUB+'?' +VER_SUF+'?' +GIT = 'git' +#------------CONFIGURATION---------------------------- + + + +def parseAndBuild(): + ''' main: parse cmdline and generate version string ''' + parser = argparse.ArgumentParser (prog=CMDNAME, description='%s: %s' % (CMDNAME, __doc__) + ,formatter_class=argparse.RawDescriptionHelpFormatter) + + parser.add_argument ('--bump','-b' + ,nargs='?' + ,choices=['maj','min','rev'], const='rev' + ,help='bump the version detected from Git (optionally bump a specific component)') + parser.add_argument ('--suffix','-s' + ,help='append (or replace) a suffix (by default attached with ~)') + parser.add_argument ('--snapshot' + ,action='store_true' + ,help='mark as development snapshot by appending ~dev.YYYYMMDDhhmm, using UTC date from HEAD commit') + + opts = parser.parse_args() + + version = getVersionFromGit() + version = rebuild (version, **vars(opts)) + print (version) + + +def getVersionFromGit(): + get_nearest_matching_tag = 'describe --tags --abbrev=0 --match=' + TAG_PAT + return runGit (get_nearest_matching_tag) + +def getTimestampFromGit(): + get_head_author_date = 'show -s --format=%ai' + timespec = runGit (get_head_author_date) + timespec = datetime.datetime.fromisoformat (timespec) + timespec = timespec.astimezone (datetime.timezone.utc) # note: convert into UTC + return timespec.strftime ('%Y%m%d%H%M') + + + +def rebuild (version, bump=None, suffix=None, snapshot=False): + mat = re.fullmatch (VER_SYNTAX, version) + if not mat: + __FAIL ('invalid version syntax in "'+version+'"') + + maj = mat.group(1) + min = mat.group(2) + rev = mat.group(3) + suf = mat.group(4) + suf_idi = mat.group(5) # detail structure not used (as of 2025) + suf_num = mat.group(6) + + if bump=='maj': + maj = bumpedNum(maj) + min = None + rev = None + elif bump=='min': + min = bumpedNum(min) + rev = None + elif bump=='rev': + rev = bumpedNum(rev) + + if snapshot: + suf = 'dev.'+getTimestampFromGit() + elif suffix: + suf = suffix + + version = maj + if min: + version += '.'+min + elif not min and rev: + version += '.0' + if rev: + version += '.'+rev + if suf: + version += '~'+suf + return version + + + +def bumpedNum (verStr): + mat = re.match (r'\d+', str(verStr)) + if not mat: + return '1' + numStr = mat.group(0) + num = int(numStr) + 1 + return str(num).zfill(len(numStr)) + + +def runGit (argStr): + ''' run Git as system command without shell and retrieve the output ''' + argList = [GIT] + argStr.split() + try: + proc = subprocess.run (argList, check=True, capture_output=True, encoding='utf-8', env={'LC_ALL':'C'}) + return proc.stdout.rstrip() # Note: sanitised env + except: + __FAIL ('invoking git-describe') + + + + +def __ERR (*args, **kwargs): + print (*args, file=sys.stderr, **kwargs) + +def __FAIL (msg): + __ERR ("FAILURE: "+msg) + exit (-1) + + +if __name__=='__main__': + parseAndBuild() diff --git a/admin/setVersion b/admin/setVersion new file mode 100755 index 000000000..ea95fe63b --- /dev/null +++ b/admin/setVersion @@ -0,0 +1,44 @@ +#!/bin/bash +# +# setVersion - place the version info given as argument +# into all the necessary places in the Lumiera tree +# +# +set -e + +function fail() { + echo -e "\nFAIL: $1\n\n" + exit -1 +} + +PROJ_ROOT=$(git rev-parse --show-toplevel) +cd $PROJ_ROOT +[ $# -eq 1 ] || fail "need version as argument\n\nsetVersion " +[ -n "$1" ] || fail "need a nonemty version spec" +VER="$1" + +function rewrite() { + # Process the indicated file with sed and replace the existing version spec + # The PREFIX argument must match everything from line start before the version; + # then the _remainder_ of this line will be replaced by the NEWVER + FILE="$1" + PREFIX="$2" + NEWVER="$3" + echo "rewrite..... $FILE" + egrep -q "^$PREFIX" $FILE || fail "not found in $FILE : $PREFIX" + # + sed -r -f - -i "$FILE" <{nbsp}{l}/project/background/GitFlow.html[Background Article]. First + link:https://nvie.com/posts/a-successful-git-branching-model/[published in 2010] + by _Vincent Driessen_, meanwhile it is widely applied in projects with regular releases + and external liabilities -- and often seen as the counterpoint to trunk centred + development and continuous delivery. + + +The Framework +------------- +The actual entity maintained in Git repositories is _a history line,_ leading to a _Head._ +Developers collaborate by pulling the history from _some other repository,_ extending or +remoulding this history by adding some changes as _commits_ and finally they publish this +extended line into their _personal repository._ However, the _normative state_ of the project +is represented by the link:https://git.lumiera.org/gitweb?p=LUMIERA[»Lumiera Repository«] +`git://git.lumiera.org/LUMIERA` + +The Core Developer(s) can _push_ to this repository, thereby acting as _Gateway._ Automated builds +will listen to this repository, and any further _downstream processes,_ like e.g. packaging, +are always based on this state. What is described in the following sections however is a +_pattern of naming and branch organisation_ -- and can be seen as orthogonal to the former: +A structure of branches and tags is assembled, gradually, in some repository; yet whenever the +Core Developer(s) push this state to the Lumiera Repository, this structure becomes the +normative state of the project. A release happens when the release tag is published this way. + +Development and Production +~~~~~~~~~~~~~~~~~~~~~~~~~~ +The development is the source of _change._ It builds the application, creates new functionality, +maintains and evolves the structure of the code. On the other side, the productive use of the +application requires _stability._ Users must be confident that they can rely on Lumiera for +reaching deadlines and to build their long-term work. These two poles are represented by the +two permanent branches: The *development mainline* and the *production master*. + +A release process brings change into a stable shape; it is represented by a *release branch*, +which originates from development, goes through a vetting process and finally _ends_ with +a *release tag* on production master. Urgent *bugfixes* are based on current production +master, and released immediately back to production with a *patch tag*. + +Every delivery to production is also *back-merged* into the development mainline one way +or another.footnote:[Some fine points to consider here. These back-merges will typically +result in merge conflicts, which require manual handling. This is a desired feature, +because reconciling the release changes with ongoing development is essential integration +work and also supports the knowledge transfer between developers; it is recommended to +consult both parties involved to find a long-term solution when resolution becomes +complicated. Note however that the version bumping both on development and for the +actual release will cause a spurious conflict, which must always be resolved in favour +of the version present on the development line. This task can be automated. And finally, +when a bugfix happens _while a release is in-flight,_ then the back-merge +*must be done to the release branch*, not the development branch -- because we need the +bugfix to be present in the next release too. Failure to observe this special rule will +cause a *regression*, i.e. loosing the fix with the next regular release.] +This is a distinguishing feature of Git-flow and addresses the quite common problem +that bugfix work can be lost for the ongoing development. + +Naming Convention +~~~~~~~~~~~~~~~~~ +master:: + the branch name used for the infinite line of production code +integration:: + the branch name used for the infinite ongoing main line of development +v:: + naming pattern for version tags; `` is the version number string + (maybe{nbsp}transliterated to make it valid for Git. Notably `'~'` -> `'_'`) +rel/:: + naming pattern for release branches; `` is the version number string + for the upcoming release. Only a single release branch is allowed at any + given time, and will be deleted after the release merge and tag is set. +fix/:: + naming pattern for bugfix branches; here `` is the patch version + string, usually with an incremented revision component (maj.min.rev). + Only a single bugfix branch is allowed at any given time; these + branches are also deleted after publishing the fix. +dev/:: + naming pattern for a development or feature branch; `` is an mnemonic + identifier, which must be unique at the time while the branch exists. + Development branches are transient and must be deleted after _landing_.footnote:[ + Sometimes a development effort does not succeed -- or is abandoned for various + reasons; if this happens, mark the last state with a tag and _delete_ the branch. + A well maintained repository should not contain stale branches.] +dev/stage dev/steam dev/vault:: + these development branch names _can_ be used for pre-integration of development + within a layer, in a situation where there is a dedicated sub-team and some + elaborated yet isolated development is going on.footnote:[As of 2025, this + situation is hypothetical; in the early stages of the Lumiera project, we + had three developers working in a relatively independent and often quite + experimental way, with several further minor contributors. In such a situation, + a staged integration can be helpful. Unless the project becomes _very large_ + eventually, it seems much more likely that long-lived feature branches will + be used for changes cross-cutting all layers.] +documentation:: + a special branch which is immediately published to the Lumiera website; + the ASCIIDOC sources of user, design and technical docs are kept in-tree + and often augmented simultaneously on several branches -- for that reason + the currently published documentation might diverge at times, and will + typically be re-joined with the development mainline during the convergence + phase before a release. This branch can be fast-forwarded and merged, + but never be re-wound or rebased. +deb:: + a special _downstream branch_ which carries the debian packaging, as + maintained by the Lumiera team and published through the Lumiera DEB depot. + This branch is not visible in the Lumiera project repository, but rather + published via a special link:https://git.lumiera.org/gitweb?p=debian/lumiera[DEB repository]. +/_signature:: + GPG signed tags from the Core Developer(s); these tags are frequently force-reset + to a new position, and indicate that this branch position was reviewed and + approved.footnote:[The relevance of such an ongoing reveiw and trust marker + is based in a preference for an open and chaotic approach to development. + People may try out things, and collaborate directly. We even maintain a + link:https://git.lumiera.org/gitweb?p=lumiera/mob[»Mob repository«] + that is _world-pushable_ for small ad-hoc contributions. This option was used + indeed, and we never had problems with vandalism. Admittedly, since several + years now the ongoing development is way too demanding and esoteric to + encourage such low-barrier access, but the vision as such is maintained, + hoping to reach a state of the project eventually where direct small-scale + contributions will be feasible again (e.g. for plug-ins, configuration, + tweaks, styling)] + +Version numbers +^^^^^^^^^^^^^^^ +The link:{rfc}/VersionNumberScheme.html[Version Number scheme of Lumiera] +is based on the Debian +link:https://www.debian.org/doc/debian-policy/ch-controlfields.html#version[policy for version numbers]; +note that this policy definition even provides a nice algorithm for version number sorting. +In a nutshell, we alternatingly compare non-numeric and numeric parts of version number strings. +And `'~'` sorts _before_ anything else, even the empty string, `'+'` sorts before `'.'` and +`'-'` (dash) is not allowed, because it is reserved for Debian revisions. + +Notably we have the convention to mark development snapshots with a version number +_preceding_ the next expected release, and we do the same with release candiates (`'rc'`); +in all those cases, we attach a suffix with a tilde, because this orders _before_ the +decorated number: `1.4~dev` comes before `1.4~rc.1` and again before `1.4` + +However, the way we use version tags, a tilde will never show up either on a +release branch, nor in the tag itself. These fine distinctions will only be used +in the version definition checked into the source tree and picked up by the build +system and thus also by the continuous integration.footnote:[as of 2025, we do not +have (and do not need yet) a continuous integration; so the actual modus operandi +still needs to be figured out.] + + +Procedures +---------- +Release process +~~~~~~~~~~~~~~~ +What follows is a short summary of the stages and procedures for a release. + +1. Prior to the release, there is a convergence phase + - attempt to land features which should be part of the release + - stabilise the code and resolve bugs + - keep breaking changes on feature branches +2. Cut the release, once the code is feature complete + - possibly adjust the expected version number based on the current situation + - fork the release branch off `integration`, using the expected version number + - bump the version number on the `integration` branch, and attach a `~dev` suffix.footnote:[ + Note there are some scripts in the 'admin' subdirectory to help with version number handling.] +3. Get the release code to maturity + - additional testing, possibly a public beta + - directly fix any bugs encountered on the release branch + - avoid any breaking changes and refrain from adding further features + - release candidates can be used simply by committing them into the version in-tree; + indicate the RC in the commit message, but do not tag them + - with the last commit, add the release notes and remove the `~rc` suffix +4. Publish the release + - merge the release branch into `master` (this will never create a conflict) + - set the release tag on this merge commit + - publish this state of the history to the Lumiera project repository +5. Complete the relase cycle + - create a back-merge from the release tag to the `integration` branch + - ensure that the integration branch has still the correct verion number, which + should be the next one, with a `~dev` suffix.footnote:[...to achieve this, just + re-run the script in a similar way as was used to bump the version after forking + the release branch.] + - resolve any conflicts due to integration of release changes with ongoing development + - delete the release branch. + +Bugfixes between Releases +^^^^^^^^^^^^^^^^^^^^^^^^^ +1. initiate bugfix + - create a bugfix branch from current `master`; include the bugfix number + - the first commit on the bugfix branch sets this bugfix number in-tree, + thereby typically adding or increasing the revision component of the version +2. landing the bugfix + - once the problem is resolved and tested, merge back bugfix branch into `master` + - merge the bugfix into `integration` + - delete the bugfix branch + +Bugfix during Release prep +^^^^^^^^^^^^^^^^^^^^^^^^^^ +1. initiate bugfix + - create a bugfix branch from current `master`; include the bugfix number + - use a version _prior_ to the ongoing release, but increment the revision component + - commit this bugfix number in-tree +2. landing the bugfix + - after resolving the problem, merge directly to `master` + - be sure to merge the bugfix then *into the release branch* + - delete the bugfix branch diff --git a/doc/technical/code/linkingStructure.txt b/doc/technical/code/LinkingStructure.txt similarity index 100% rename from doc/technical/code/linkingStructure.txt rename to doc/technical/code/LinkingStructure.txt diff --git a/doc/technical/code/index.txt b/doc/technical/code/index.txt index 9f44e14a0..eaaffa3e4 100644 --- a/doc/technical/code/index.txt +++ b/doc/technical/code/index.txt @@ -2,6 +2,9 @@ Code Base Organisation ====================== //Menu: label Code Base +//Menu: prepend child CodingGuidelines +//Menu: put child LinkingStructure after CodingGuidelines +//Menu: put child GitBranching after LinkingStructure This section of Lumiera's technical documentation deals with the code base as such, diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 5c53df286..217bd36a3 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -160223,8 +160223,6 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - @@ -160244,6 +160242,8 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + @@ -160713,12 +160713,12 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + - + @@ -161012,7 +161012,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161037,11 +161037,498 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + + + + + + + + + +

+ Hier sollen Inhalte veröffentlicht werden, die über eine reine technische Dokumentation hinausgehen. Das reicht von einer Darstellung der Projekthistorie, über Recherche und gesammeltem thematischen Wissen bis zur Aufsätzen zu allgemeinen Begriffsbestimmungen und Maßstäben. +

+ + + + + + + +

+ Da Lumiera.org explizit dafür sorgt, längerfristig im Internet-Archiv präsent zu sein, und zudem längerfristig auf Verlinkung hoffen kann, sollten hier abgelegte Texte stabil sein und könnten ggfs. extern als Quellen referenziert werden; im Besonderen denke ich hier an eine Sammlung von Wissen, Methoden und Verfahren. +

+ + + + + + + +

+ das heißt, hier bewege ich mich auf einem schmalen Grat +

+
    +
  • + erhoffe mir Sichtbarkeit für meine eigenen Einsichten +
    • +
  • + kann aber auch Richtlinien und Maßstäbe verbindlich setzen +
    • +
+ + + + + + + + + + + + +

+ da dieser Content unweigerlich wächst, ist die Historie des Website-Repos nicht für die Ewikeit und könnte rewritten werden +

+ + + + + + + + + +

+ per hart gecodeter Mapping-Regel in menugen.py — addPredefined() +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ auf lange Sicht werde ich selber diese Arbeiten ausführen +

+ + + + + +

+ ....und deshalb muß das Schema nicht so elaboriert sein, wie es für einen Release-Train mit vielen Projekten notwendig wäre; wichtiger ist, daß das Ergebnis selbsterklärend ist. Später kann man diese Prozedur wohl komplett skripten +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Nachdem die Code-Basis grundsätzlich reif ist für ein Release, wird hiermit die Konvergenz-Phase eingeleitet, und die Haupt-Entwicklung wieder freigegeben... +

+
    +
  • + ein Release-Branch wird abgezweigt +
    • +
  • + auf dem Integration(Mainline)-Branch findet der Versions-Bump statt +
    • +
+ + + + + + + + +

+ Nachdem die Konvergenz-Phase abgeschlossen wurde, muß nun das Release nur noch formal vollzogen werden.... +

+
    +
  • + (idealerweise schreibt man vorher als letzten Commit die Release-Notes) +
    • +
  • + es findet ein back-Merge statt auf den Integration(Mainline)-Branch +
    • +
+ + + + + + + + +

+ Nachdem nichts mehr zu committen ist und auch der Build nochmal getestet wurde.... +

+
    +
  • + setzt ein letzter formalisierter Commit auf dem Release-Branch die Release-Version +
    • +
  • + der Release-Branch wird auf den Master-Branch geMerged +
    • +
  • + auf diesen Merge wird das Release-Tag gesetzt +
    • +
  • + der Release-Branch wird gelöscht +
    • +
  • + dieser Stand in Git wird publiziert +
    • +
  • + automatisierte CI-Aktionen werden initiiert +
    • +
+ + + + + + + + + + + +

+ Ein Hotfix kann jederzeit ohne Vorbedingungen begonnen werden +

+
    +
  • + ein Hotfix-Branch wird vom letzten Release-Commit abgezweigt +
    • +
  • + der Eröffnungs-Commit ist formalisiert und beinhaltet einen Version-bump < current-devel +
    • +
+ + + + + + + + +

+ Nachdem Test und Validierung abgeschlossen sind +

+
    +
  • + erfolgt ein Merge-Commit normalerweise auf Integration(mainline) +
    • +
  • + sofern allerdings ein Release-Branch existiert, wird auf diesen gemerged; dabei kommt es zu einem Konflikt mit der Versionsnummer, welcher zugunsten der Release-Version aufzulösen ist (diese ist stets höher) +
    • +
+ + + + + + + + +

+ Nachdem alle Arbeiten abgeschlossen sind und der Code-Stand so publiziert werden könnte... +

+
    +
  • + erfolgt direkt ein Merge auf den Master-Branch +
    • +
  • + auf diesen wird ein Tag gesetzt +
    • +
  • + der Hotfix-Branch wird gelöscht +
    • +
+ + + + + + + + + + +

+ Ein Feature kann jederzeit begonnen werden und soll regelmäßig re-based werden +

+
    +
  • + ein formalisierter erster Commit setzt eine dekorierte Version und legt den Branch an +
    • +
+ + + + + + + + +

+ Nachdem ein Feature so weit ist, daß es den Stand auf Integration(mainline) nicht mehr gefährdet... +

+
    +
  • + (sollte ggfs. zunächst nochmal manuell ein Rebase erfolgen) +
    • +
  • + erfolgt automatisch ein Rebase, welches den Feature-Versions-Commit wegläßt +
    • +
  • + sofern danach nur maximal zwei Commits übrigbleiben, kaönnen diese direkt per fast-forward übernommen werden +
    • +
  • + sonst wird ein no-fast-forward-Merge auf Integration(Mainline) gemacht +
    • +
+ + + + + + + + + + + + + + + + + + + + + + +

+ Das Lumiera-Versionsnummern-Schema baut auf der Debian-Policy für Versionsnamen auf, und beinhaltet aber zusätzlich einige Entscheidungen, wie die ALPHA und BETA-Phase dargestellt wird, und wie man Development-Snapshots markiert +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ wenn wir den master vorerst stehen lassen, dann kann er nach dem nächsten Release nahtlos in die neue Rolle wechseln; d.h. wir mergen das neue release noch in den alten release-Branch, und dann spulen wir master einfach dorthin +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -162231,7 +162718,7 @@ actively maintained upstream. Please remove gdl from Debian. - + @@ -165893,7 +166380,8 @@ Since then others have made contributions, see the log for the history. - + + @@ -166140,6 +166628,7 @@ Since then others have made contributions, see the log for the history. + @@ -167117,6 +167606,7 @@ Since then others have made contributions, see the log for the history. + @@ -168447,7 +168937,8 @@ Since then others have made contributions, see the log for the history. - + + @@ -168712,8 +169203,8 @@ Since then others have made contributions, see the log for the history. - - + + @@ -168724,7 +169215,7 @@ Since then others have made contributions, see the log for the history. - + @@ -168733,38 +169224,38 @@ Since then others have made contributions, see the log for the history. - - - + + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - + @@ -169660,10 +170151,95 @@ Since then others have made contributions, see the log for the history. - - + + + + + + + - + + + + + + + + +

+ das ist wichtig, denn damit ist das stets das nächstgelegene Release-Tag, was man für Skripting ausnützen kann. +

+ + + + + + + + +

+ Guten Einschnitt finden; abgeschlossene Features landen, möglichst noch obsoleten Code wegräumen. Und wichtig: rechtzeitig aufhören mit den tiefgreifenden Änderungen; besser Tests schreiben, an Details feilen, Untiefen ausloten. +

+ + + + + + + + +

+ Die aktuelle Version, die nun released werden soll; sie sollte zu dem Zeitpunkt noch mit einem ~dev -  Suffix versehen sein, aber so in-tree selber eingecheckt sein (im Buildsystem oder einer Konfigdatei). +

+

+ +

+

+ Manchmal kommt es vor, daß erst kurz vor einem Release feststeht, daß man nun eine minor oder gar eine major-Version machen wird; daher muß man dann die eingecheckte Konfiguration anpassen und hochziehen. In einem solchen Fall ist es dann auch nicht möglich, die nächste Version einfach aus dem letzten Git-Tag zu gewinnen. (TODO: später mal ein elaborierteres Scripting, das auch die Version in-tree berücksichtigt) +

+ + + + + + + + +

+ Hiermit wird der Release-Stand(Features) festgesetzt und die Entwicklung ist wieder freigegeben +

+ + + + + + + + + + + + + +

+ Klarstellung: das wird die nächste Version nach diesem Release +

+ + + + + + + + + + + + + + + @@ -169673,7 +170249,6 @@ Since then others have made contributions, see the log for the history. - @@ -169708,57 +170283,7 @@ Since then others have made contributions, see the log for the history. - - - - -

- knappe Kennzeichnung des Releases in den Kommentar -

- - - - - - - - - - - - -

- hier geht es darum, Konsistenz im Git herzustellen. -

-

- Wenn alles korrekt gemacht wurde, dürfte es hier keinen Rückfluß von Änderungen geben. -

-

- Bitte auch daran denken, zuerst den DEB-Zweig zu prüfen. Diesen aber nicht zurückmergen, -

-

- denn wir wollen keine DEB-Info im Master haben! -

- - - - - - - - - - - -

- einzeilige Kennzeichnung wiederholen -

-

- die unmittelbaren Release-Dokumente durchgehen -

- - - + @@ -169770,22 +170295,54 @@ Since then others have made contributions, see the log for the history. - + + + + + + + + + + + + + + + + + +

- Merge-commit auf den Release-Zweig. -

-

- Sollte konfliktfrei sein + der Release-branch sollte zuletzt direkt auf dem Merge-Commit stehen; Grund ist: wir wollen dann von dort nach integration mergen (und automatisch die richtige Commit-Msg bekommen: merging rel/#.#.# into integration)

- - + + + + + + + + + + + + + + + + + + + + @@ -169794,7 +170351,7 @@ Since then others have made contributions, see the log for the history. - + @@ -169803,7 +170360,7 @@ Since then others have made contributions, see the log for the history. - + @@ -170082,8 +170639,7 @@ Since then others have made contributions, see the log for the history. - - + @@ -170093,7 +170649,7 @@ Since then others have made contributions, see the log for the history. - + @@ -170152,6 +170708,34 @@ Since then others have made contributions, see the log for the history. + + + + + + + + + + + + + + + + + + + + + + + + + + + +