Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
tails
tails
Commits
b3515fea
Commit
b3515fea
authored
Oct 22, 2018
by
intrigeri
Browse files
Consistently use "bugfix release" terminology.
… and not "point-release" nor "minor release".
parent
81789ae3
Changes
12
Hide whitespace changes
Inline
Side-by-side
wiki/src/blueprint/monthly_report.mdwn
View file @
b3515fea
...
...
@@ -98,7 +98,7 @@ Template
Releases
========
* \[[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|
minor
|emergency] release).
* \[[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|
bugfix
|emergency] release).
* Tails VERSION+1 is \[[scheduled for MONTH DAY|contribute/calendar]].
...
...
wiki/src/blueprint/monthly_report/report_2018_10.mdwn
View file @
b3515fea
...
...
@@ -7,7 +7,7 @@
Releases
========
* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|
minor
] release).
* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|
bugfix
] release).
* Tails VERSION+1 is [[scheduled for MONTH DAY|contribute/calendar]].
...
...
wiki/src/blueprint/monthly_report/report_2018_11.mdwn
View file @
b3515fea
...
...
@@ -7,7 +7,7 @@
Releases
========
* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|
minor
] release).
* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|
bugfix
] release).
* Tails VERSION+1 is [[scheduled for MONTH DAY|contribute/calendar]].
...
...
wiki/src/blueprint/monthly_report/report_2018_12.mdwn
View file @
b3515fea
...
...
@@ -7,7 +7,7 @@
Releases
========
* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|
minor
] release).
* [[Tails VERSION was released on MONTH DAY|news/version_VERSION]] ([major|
bugfix
] release).
* Tails VERSION+1 is [[scheduled for MONTH DAY|contribute/calendar]].
...
...
wiki/src/contribute/APT_repository.mdwn
View file @
b3515fea
...
...
@@ -57,7 +57,7 @@ release (`testing`):
Tails ISO build).
When building an ISO from the branch used to prepare the next
point-
release (`stable`) we use the same time-based snapshots that
bugfix
release (`stable`) we use the same time-based snapshots that
were used to prepare the latest Tails release, except:
* we use our latest snapshot of security.debian.org;
...
...
wiki/src/contribute/APT_repository/custom.mdwn
View file @
b3515fea
...
...
@@ -363,16 +363,16 @@ In any case:
-m "Add dummy changelog entry for ${NEXT_PLANNED_MAJOR_VERSION:?}."
* increment the version number in stable's `debian/changelog` to match
the next
point
release, so that
the next
bugfix
release, so that
next builds from the `stable` branch do not use the APT suite meant
for the last release:
cd "${RELEASE_CHECKOUT}" && \
git checkout stable && \
dch --newversion "${NEXT_PLANNED_
MINOR
_VERSION:?}" \
dch --newversion "${NEXT_PLANNED_
BUGFIX
_VERSION:?}" \
"Dummy entry for next release." && \
git commit debian/changelog \
-m "Add dummy changelog entry for ${NEXT_PLANNED_
MINOR
_VERSION:?}."
-m "Add dummy changelog entry for ${NEXT_PLANNED_
BUGFIX
_VERSION:?}."
### Else, if you just released a RC
...
...
wiki/src/contribute/design.mdwn
View file @
b3515fea
...
...
@@ -1346,7 +1346,7 @@ Remaining applications, including the base system, will be upgraded
using Debian standard upgrade process, and generally based on the
latest Debian stable release so there are not many problems.
We intend to build and publish
point
releases (e.g.
We intend to build and publish
bugfix
releases (e.g.
[[0.6.1|news/version_0.6.1]]) in a timely manner when security issues
affect Tails. Such releases are based on the [[stable Git
branch|contribute/git]] and can thus also fix important — although not
...
...
wiki/src/contribute/design/incremental_upgrades.mdwn
View file @
b3515fea
...
...
@@ -53,7 +53,7 @@ Test-BDD-Cucumber]], in the `features/frontend` directory of the `iuk`
## As a Tails developer
### When I prepare a
point-
release
### When I prepare a
bugfix
release
#### I should prepare an IUK
...
...
wiki/src/contribute/how/code/HACKING.mdwn
View file @
b3515fea
...
...
@@ -27,7 +27,7 @@ you have something to contribute, please read our
up. In general you should base new branches on this one.
* `stable`: When a new major Tails release is out, we merge `devel`
into `stable` and use it to build
minor
releases (e.g. when there's
into `stable` and use it to build
bugfix
releases (e.g. when there's
a new Tor Browser (= Firefox ESR) release) and emergency releases
from. We only merge security fixes and bugfixes into this branch, so
new such branches should be based on `stable`.
...
...
wiki/src/contribute/how/documentation/release_notes.mdwn
View file @
b3515fea
...
...
@@ -15,10 +15,10 @@
- If a release candidate was announced, read the call for testing
- Analyze the changes already made on the website and link to them:
- in testing for a major release: `git diff origin/master...origin/testing wiki/src/**/*.{mdwn,html}`
- in stable for a
minor
release: `git diff origin/master...origin/stable wiki/src/**/*.{mdwn,html}`
- in stable for a
bugfix
release: `git diff origin/master...origin/stable wiki/src/**/*.{mdwn,html}`
- Analyze the diff of packages
- in testing for a major release: `wget http://nightly.tails.boum.org/build_Tails_ISO_testing/lastSuccessful/archive/latest.iso.packages`
- in stable for a
minor
release: `wget http://nightly.tails.boum.org/build_Tails_ISO_stable/lastSuccessful/archive/latest.iso.packages`
- in stable for a
bugfix
release: `wget http://nightly.tails.boum.org/build_Tails_ISO_stable/lastSuccessful/archive/latest.iso.packages`
- `diff -u ~/Persistent/master/wiki/src/torrents/files/tails-amd64-*.packages latest.iso.packages | wdiff --diff-input --terminal --auto-pager`
- If an important application was updated to a new upstream release, read its Changelog to find relevant highlights:
- Tor: <https://blog.torproject.org/>
...
...
wiki/src/contribute/release_process.mdwn
View file @
b3515fea
...
...
@@ -48,8 +48,8 @@ the scripts snippets found on this page:
the 3.9 major release, then set this to 3.12 (3.9 is the next major
release, 3.10 and 3.11 are bugfix releases, 3.12 is a major
release).
* `NEXT_PLANNED_
MINOR
_VERSION`: set to the version number of the next
*
minor
* Tails release; if the next release is a
point-
release, use
* `NEXT_PLANNED_
BUGFIX
_VERSION`: set to the version number of the next
*
bugfix
* Tails release; if the next release is a
bugfix
release, use
that one; otherwise, use `${VERSION}.1`
* `MAJOR_RELEASE`: set to 1 if preparing a major release or a release
candidate for a major release, to 0 otherwise
...
...
@@ -124,10 +124,10 @@ If we are at freeze time for a major release:
[[APT_repository/time-based_snapshots#bump-expiration-date-for-all-snapshots]]
Point-
release
-------------
Bugfix
release
-------------
-
If we are at freeze time for a
point-
release:
If we are at freeze time for a
bugfix
release:
1. Merge the `master` Git branch into `stable`:
...
...
@@ -137,8 +137,8 @@ If we are at freeze time for a point-release:
listed in the `stable` branch's `config/APT_overlays.d/` into the `stable`
APT suite.
Common steps for
point
and major releases
-----------------------------------------
Common steps for
bugfix
and major releases
-----------------------------------------
-
Reset the release branch's `config/base_branch`:
...
...
@@ -163,7 +163,7 @@ Update included files
Upgrade bundled binary Debian packages
--------------------------------------
Skip this section if you are preparing a
point-
release.
Skip this section if you are preparing a
bugfix
release.
The goal here is to make sure the bundled binary Debian packages contain
up-to-date localization files, so:
...
...
@@ -257,11 +257,11 @@ Major release
listed in the `testing` branch's `config/APT_overlays.d/` into the `testing`
custom APT suite.
Point-
release
-------------
Bugfix
release
-------------
-
<div class="note">
For
point-
releases, we generally do not put any RC out, so freeze time
For
bugfix
releases, we generally do not put any RC out, so freeze time
is the same as preparing the actual release. Hence, the following
steps have already been done above, and this section is a noop in the
general case.
...
...
@@ -761,7 +761,7 @@ Prepare upgrade-description files
--version "${VERSION:?}" \
--next-version "${NEXT_PLANNED_MAJOR_VERSION:?}" \
--next-version "${NEXT_PLANNED_MAJOR_VERSION:?}~rc1" \
--next-version "${NEXT_PLANNED_
MINOR
_VERSION:?}" \
--next-version "${NEXT_PLANNED_
BUGFIX
_VERSION:?}" \
--next-version "${VERSION:?}.1" \
--iso "${ISO_PATH:?}" \
--previous-version "${PREVIOUS_VERSION:?}" \
...
...
wiki/src/contribute/release_schedule.mdwn
View file @
b3515fea
...
...
@@ -47,7 +47,7 @@ Postponing the final release causes problems for those who have
scheduled time for post-release user support, press work, etc..
Also, changing our mind (i.e. releasing a point-release instead of
a major one) => switching
minor
/major release schedule for the future
a major one) => switching
bugfix
/major release schedule for the future
is probably not an option either.
So we need to have a pessimistic enough RC->final schedule to handle
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment