Diff for "FeatureHighlights/ProductSeries"

Not logged in - Log In / Register

Differences between revisions 5 and 6
Revision 5 as of 2007-03-26 16:24:41
Size: 4544
Editor: 81
Comment:
Revision 6 as of 2007-03-27 10:56:59
Size: 4490
Editor: 217
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Series: Major stable and development branches = = Series: major stable and development branches =
Line 3: Line 3:
When we think of the way a project organises itself, there are some branches which are special - they represent major lines of development, and releases are "cut" from them. Typically these branches represent: When we think of the way a project organises itself, there are some special branches: they represent major lines of development, and releases are "cut" from them. Typically these branches represent:
Line 5: Line 5:
 * the "'''development trunk'''", which is the current "tip" of development across the core project community, it represents the very cutting edge of work on that project. In general, the only releases made from the development trunk are snapshot, milestone or test releases to generate more widespread testing and feedback.  * '''Development trunk:''' this is the current "tip" of development across the core project community, representing the very cutting edge of work on that project. In general, the only releases made from the development trunk are snapshot, milestone or test releases, to generate more widespread testing and feedback.
Line 7: Line 7:
 * one or more '''stable and supported''' branches. These represent the latest work done on the stable versions of the project which are still supported. If updated stable releases are to be made they will come from these branches.  * '''Stable and supported branches:''' these represent the latest work on the stable versions of the project, which are still supported. If updated stable releases are to be made they will come from these branches.
Line 9: Line 9:
 * possibly, some '''obsolete''' branches, for major release versions that are now out of date and no longer being updated. These branches likely do not get any further work done on them.  * '''Obsolete branches:''' for major release versions that are now out of date and no longer being updated. It's likely that work is no longer done on these branches.
Line 11: Line 11:
We call each of these "major" lines of development a "series", because it primarily represents a "series of releases of the same major version". We call each of these "major" lines of development a "series", because they primarily represent a "series of releases of the same major version".
Line 13: Line 13:
Note, there are usually multiple series for a given project, especially one that has produced stable releases. For example, a project might have a version 1.2 which is still supported, a 1.3 which is the "latest stable version" and recommended for new users, and a trunk which represents the current line of active development and the source of snapshot test releases for the next stable version. Note, there are usually multiple series for a given project, especially one that has produced stable releases. For example, a project might have a version 1.2 which is still supported, a 1.3 which is the "latest stable version" and recommended for new users, and a trunk which represents the current line of active development and is the source of snapshot test releases for the next stable version.
Line 25: Line 25:
There's some flexibility in the way projects name and organise themselves. For example, in the GNOME project, the "development trunk" is like a series with an "odd" version number, like 2.17, and when it is ready for release it gets branched with an "even" version number like 2.18. Then once the stable release is made, it gets branched to 2.19, which is the new "trunk". Sometimes projects also call the trunk "MAIN", a term from the days of CVS. In the Zope3 example above, the 3.4 series was the trunk at the time of writing. === Naming series ===
Line 27: Line 27:
For convention, we encourage projects to call their development focus "trunk" and leave it as the same branch over time. When creating a new stable series, branch from trunk, create the series and link the branch to that series. This ensures that people who create a checkout of "trunk" don't find that it goes stale because it has "become a stable series" suddenly. And those who checkout or branch from a stable series will get what they expect, too. There's some flexibility in the way projects name and organise themselves. For example, in the GNOME project, the "development trunk" is a series with an "odd" version number, such as 2.17. When it is ready for release, it is branched with an "even" version number, such as 2.18. Once GNOME make the stable release, the branch it to create 2.19, the new "trunk".
Line 29: Line 29:
== Series and Branches == Sometimes, projects also call the trunk "MAIN", a term from the days of CVS. In the Zope3 example above, the 3.4 series was the trunk at the time of writing.
Line 31: Line 31:
In Launchpad, each project can have multiple Series registered, and each of those Series can be associated with a branch. By default, if you don't specify which series you are interested in, you will get the current development trunk series ('''usually''' called trunk, but not always). For example, in the example where you branched GNU Hello, you typed: For convention, we encourage projects to call their development focus "trunk" and leave it as the same branch over time. When creating a new stable series, branch from trunk, create the series and link the branch to that series. This ensures that people who create a checkout of "trunk" don't find that it goes stale because it has been turned into a stable series, suddenly. And those who checkout or branch from a stable series will get what they expect, too.

== Series and branches ==

In Launchpad, each project can register multiple series. Each of those series can be associated with a branch. By default, if you don't specify which series you are interested in, you will get the current development trunk series ('''usually''' called trunk, but not always). For example, in the example where you branched GNU Hello, you typed:
Line 38: Line 42:
This command specifies only the project name, so you would have been given the development trunk. If there was a 1.3 series with a branch associated with it, you could have typed {{{bzr branch http://launchpad.net/gnuhello/1.3}}} and received the tip of that stable branch. Note that this is different to the previous approach of branching from a specific person's version of a project - here you are branching from one of the "major project branches", or Series. This command specifies only the project name, so you would have been given the development trunk. If there was a 1.3 series with a branch associated with it, you could have typed {{{bzr branch http://launchpad.net/gnuhello/1.3}}} and received the tip of that stable branch.
Line 40: Line 44:
Not every Series will have a branch associated with it. Often, Series are registered so that they can be a handle for a set of translations for a particular major version of the software, or so that bugs can be targeted there for release management. But we do encourage you to make sure, when you branch from trunk to make a new major stable release, that you setup a Series for it and link the branch to it. Note that this is different to the previous approach of branching from a specific person's version of a project. Here you are branching from one of the "major project branches", or series.
Line 42: Line 46:
What if the project isn't yet using Bazaar officially, and code is being managed in CVS or Subversion? Launchpad can import the CVS or SVN trunk of the project and publish it for you as a Bazaar branch - and then keep it up to date so you can work entirely in Bazaar, merging from trunk whenever you want. That's the [:ReviewersGuide/BranchImports:next step] in this tour. Not every series has a branch associated with it. Often, series are registered to handle a set of translations for a particular major version of the software, or so that bugs can be targeted there for release management. But we do encourage you to make sure, when you branch from trunk to make a new major stable release, that you set up a series for it and link the branch to it.

What if the project isn't yet using Bazaar officially, and code is being managed in CVS or Subversion? Launchpad can import the CVS or SVN trunk of the project and publish it for you as a Bazaar branch - and then keep it up to date so you can work entirely in Bazaar, merging from trunk whenever you want.

That's the [:ReviewersGuide/BranchImports:next step] in this tour.

Series: major stable and development branches

When we think of the way a project organises itself, there are some special branches: they represent major lines of development, and releases are "cut" from them. Typically these branches represent:

  • Development trunk: this is the current "tip" of development across the core project community, representing the very cutting edge of work on that project. In general, the only releases made from the development trunk are snapshot, milestone or test releases, to generate more widespread testing and feedback.

  • Stable and supported branches: these represent the latest work on the stable versions of the project, which are still supported. If updated stable releases are to be made they will come from these branches.

  • Obsolete branches: for major release versions that are now out of date and no longer being updated. It's likely that work is no longer done on these branches.

We call each of these "major" lines of development a "series", because they primarily represent a "series of releases of the same major version".

Note, there are usually multiple series for a given project, especially one that has produced stable releases. For example, a project might have a version 1.2 which is still supported, a 1.3 which is the "latest stable version" and recommended for new users, and a trunk which represents the current line of active development and is the source of snapshot test releases for the next stable version.

Take a look at the Zope3 project:

The stable and trunk series are shown in the "Timeline" section of the page:

  • attachment:zope3series.png

The trunk series here is identified with the words "Current development focus".

Naming series

There's some flexibility in the way projects name and organise themselves. For example, in the GNOME project, the "development trunk" is a series with an "odd" version number, such as 2.17. When it is ready for release, it is branched with an "even" version number, such as 2.18. Once GNOME make the stable release, the branch it to create 2.19, the new "trunk".

Sometimes, projects also call the trunk "MAIN", a term from the days of CVS. In the Zope3 example above, the 3.4 series was the trunk at the time of writing.

For convention, we encourage projects to call their development focus "trunk" and leave it as the same branch over time. When creating a new stable series, branch from trunk, create the series and link the branch to that series. This ensures that people who create a checkout of "trunk" don't find that it goes stale because it has been turned into a stable series, suddenly. And those who checkout or branch from a stable series will get what they expect, too.

Series and branches

In Launchpad, each project can register multiple series. Each of those series can be associated with a branch. By default, if you don't specify which series you are interested in, you will get the current development trunk series (usually called trunk, but not always). For example, in the example where you branched GNU Hello, you typed:

  • % bzr branch http://launchpad.net/gnuhello
    191 revisions branched.

This command specifies only the project name, so you would have been given the development trunk. If there was a 1.3 series with a branch associated with it, you could have typed bzr branch http://launchpad.net/gnuhello/1.3 and received the tip of that stable branch.

Note that this is different to the previous approach of branching from a specific person's version of a project. Here you are branching from one of the "major project branches", or series.

Not every series has a branch associated with it. Often, series are registered to handle a set of translations for a particular major version of the software, or so that bugs can be targeted there for release management. But we do encourage you to make sure, when you branch from trunk to make a new major stable release, that you set up a series for it and link the branch to it.

What if the project isn't yet using Bazaar officially, and code is being managed in CVS or Subversion? Launchpad can import the CVS or SVN trunk of the project and publish it for you as a Bazaar branch - and then keep it up to date so you can work entirely in Bazaar, merging from trunk whenever you want.

That's the [:ReviewersGuide/BranchImports:next step] in this tour.

FeatureHighlights/ProductSeries (last edited 2008-06-17 14:21:20 by localhost)