diff --git a/VersionScheme.md b/VersionScheme.md index 667684dd..793e5c9b 100644 --- a/VersionScheme.md +++ b/VersionScheme.md @@ -8,36 +8,111 @@ redirect_from: /wiki/VersionScheme/ Version Scheme ============== -Beginning with R3 release, we change (and formalise) the versioning scheme. From now on, it will be as follows. +Beginning with R3 release, we change (and formalise) the versioning scheme. +From now on, it will be as follows. Qubes distributions and products -------------------------------- -We intend to make it easy to make a remix of qubes, targetting another hypervisor or isolation provider. We may also create commercial products intended for specific circumstances. There is one distinguished distribution called **Qubes OS**. All source code for it is available for download under GPL licence and is openly developed on the mailing lists. The rest of this document discusses Qubes OS. Another remix may have its own version series. +We intend to make it easy to make a remix of qubes, targetting another +hypervisor or isolation provider. We may also create commercial products +intended for specific circumstances. There is one distinguished distribution +called **Qubes OS**. All source code for it is available for download under GPL +licence and is openly developed on the mailing lists. The rest of this document +discusses Qubes OS. Another remix may have its own version series. Release version --------------- -Qubes OS as a whole is released from time to time. Version scheme for all releases is modelled after Linux kernel version numbers. When announcing new release, we decide on the major.minor version (like `3.0`) and release `3.0-rc1`. When we feel that enough progress has been made, we put `3.0-rc2` and so on. All these versions are considered unstable and not ready for production. You may ask for support on mailing lists (specifically **qubes-devel**), but it is not guaranteed (you may for example get answer „update to newer `-rc`”). Public ISO image may or may not be available. +Qubes OS as a whole is released from time to time. Version scheme for all +releases is modelled after Linux kernel version numbers. When announcing new +release, we decide on the major.minor version (like `3.0`) and release +`3.0-rc1`. When we feel that enough progress has been made, we put `3.0-rc2` +and so on. All these versions are considered unstable and not ready for +production. You may ask for support on mailing lists (specifically +**qubes-devel**), but it is not guaranteed (you may for example get answer +„update to newer `-rc`”). Public ISO image may or may not be available. -When enough development has been made, we announce the first stable version, like e.g. `3.0.0` (i.e. without `-rc`). This version is considered stable and we support it for some period. Core components are branched at this moment and bugfixes are backported from master branch. Questions about stable release should be directed to the **qubes-users** mailing list. No major features and interface incompatibilities are to be included in this release. We release bugfixes as `3.0.1`, `3.0.2` and so on, while new features come into the next release e.g. `3.1-rcX`. +When enough development has been made, we announce the first stable version, +like e.g. `3.0.0` (i.e. without `-rc`). This version is considered stable and +we support it for some period. Core components are branched at this moment and +bugfixes are backported from master branch. Questions about stable release +should be directed to the **qubes-users** mailing list. No major features and +interface incompatibilities are to be included in this release. We release +bugfixes as `3.0.1`, `3.0.2` and so on, while new features come into the next +release e.g. `3.1-rcX`. -Tickets in the tracker are sorted out by release major.minor, such as `3.0`, `3.1` (trac calls this „milestone”). +Tickets in the tracker are sorted out by release major.minor, such as `3.0`, +`3.1` (trac calls this „milestone”). + +Release schedule +---------------- + +There is no specific schedule for major and minor other that more general +roadmap. When time comes, Supreme Committee declares feature freeze and tags +`-rc1` and releases ISO image. From this time on, no new features are accepted. +Also a strict time schedule kicks in. + +Each release candidate period is as follows. For the first two weeks we accept +and assign bugreports to be fixed before next release candidate. For the next +two weeks we generally focus on fixing assigned bugreports, so issues discovered +during this time may be postponed until later RC. Finally after that there is +one week of current-testing freeze, during which time no new packages are +released, in hope that they will be installed by wider user base and tested. + +The next RC is released five weeks after the former. All packets are published +in `current` repository and the cycle starts over. There should be no less than +1 and no more than 3 release candidates before final release. + + + + + + + + + + +
stagetime
initial testing2 weeks
bug fixing2 weeks
`current-testing` freeze1 week
+ +Starting with second cycle (that is, after `-rc1`) two weeks into the cycle +(after primary bug-reporting period) the Supreme Committee decides wether there +should be another RC. If, based on remaining issues, the Committee decides to +release final, then the Committee agrees upon the release date, which should be +no later than a week after. Component version ----------------- -Qubes release is defined as specific versions of components, which are developed more or less separately. Their versions are composed of major and minor version of target Qubes OS release followed by third component which is just incremented. There is no apparent indication that given version is stable or not. +Qubes release is defined as specific versions of components, which are +developed more or less separately. Their versions are composed of major and +minor version of target Qubes OS release followed by third component which is +just incremented. There is no apparent indication that given version is stable +or not. -There are some non-essential components like `qubes-apps-*` that are shared between releases. Their versions indicate oldest qubes-release that is supported. We try hard to support multiple releases by one branch to ease code maintenance. +There are some non-essential components like `qubes-apps-*` that are shared +between releases. Their versions indicate oldest qubes-release that is +supported. We try hard to support multiple releases by one branch to ease code +maintenance. -Different Qubes releases remixes may comprise of different components and version are not guaranteed to be monotonic between releases. We may decide that for newer release some component should be downgraded. There is no guarantee that arbitrary combination of different versions of random components will yield usable (or even install-able) compilation. +Different Qubes releases remixes may comprise of different components and +version are not guaranteed to be monotonic between releases. We may decide that +for newer release some component should be downgraded. There is no guarantee +that arbitrary combination of different versions of random components will +yield usable (or even install-able) compilation. Git tags and branches --------------------- -We mark each component version in the repository by tag containing `v`. Likewise, each Qubes OS release is marked by `R` tag. +We mark each component version in the repository by tag containing +`v`. Likewise, each Qubes OS release is marked by `R` tag. -At the release of some release we create branches named like `release2`. Only bugfixes and compatible improvements are backported to these branches. These branches should compile. All new development is done in `master` branch. This branch is totally unsupported and may not even compile depending on maintainer of repository. +At the release of some release we create branches named like `release2`. Only +bugfixes and compatible improvements are backported to these branches. These +branches should compile. All new development is done in `master` branch. This +branch is totally unsupported and may not even compile depending on maintainer +of repository. -All version and release tags should be made and signed by someone from ITL staff. Public keys are included in `qubes-builder` and available at [http://keys.qubes-os.org/keys/](http://keys.qubes-os.org/keys/). +All version and release tags should be made and signed by someone from ITL +staff. Public keys are included in `qubes-builder` and available at +[http://keys.qubes-os.org/keys/](http://keys.qubes-os.org/keys/). diff --git a/releases/3.0/release-notes.md b/releases/3.0/release-notes.md new file mode 100644 index 00000000..c68ba475 --- /dev/null +++ b/releases/3.0/release-notes.md @@ -0,0 +1,30 @@ +--- +layout: doc +title: Qubes R3.0 release notes +permalink: /doc/releases/3.0/release-notes/ +--- + +Qubes R3.0 release notes +======================== + +*this page is a draft for yet unreleased version* + +New features since 2.0 +---------------------- + +* Xen 4.4 +* Qrexec 3 +* Debian templates +* Whonix templates +* Build system improvements + +Known issues +------------ + +* Windows Tools: `qvm-block` does not work + +Downloads +--------- + +Installation instructions +------------------------- diff --git a/releases/3.0/schedule.md b/releases/3.0/schedule.md new file mode 100644 index 00000000..483f21eb --- /dev/null +++ b/releases/3.0/schedule.md @@ -0,0 +1,22 @@ +--- +layout: doc +title: Qubes R3.0 release schedule +permalink: /doc/releases/3.0/schedule/ +--- + +Qubes R3.0 release schedule +=========================== + + + + + + + + current-testing freeze + + + + + +
datestage
3.0-rc2
5.09.2015
3.0-rc3
15.09.2015ISO
3.0
1.10.2015ISO
diff --git a/releases/todo.md b/releases/todo.md new file mode 100644 index 00000000..a2af9581 --- /dev/null +++ b/releases/todo.md @@ -0,0 +1,31 @@ +--- +layout: doc +title: Release checklist +permalink: /doc/releases/todo/ +--- + +Release checklist +================= + +*the checklist is probably unfinished* + +On -rc1 +------- +* write schedule +* push all packages to `current-testing` +* draft release notes, one note per feature +* build ISO and push to mirrors + +On subsequent -rc +----------------- +* push packages to `current` +* update release notes +* build ISO and push to mirrors + +On final release +---------------- +* push packages to `current` +* finish release notes +* build ISO and push to mirrors +* write blog post +* announce on Twitter