Diff for "Projects/SeriesMilestonesReleases"

Not logged in - Log In / Register

Differences between revisions 12 and 13
Revision 12 as of 2009-06-26 13:03:22
Size: 7147
Editor: 92-237-59-186
Comment:
Revision 13 as of 2010-06-25 18:34:41
Size: 7222
Editor: pool-71-163-158-16
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
Let's look at how you can use Launchpad to plan your project's development and to record releases: Let's look at how you can use Launchpad to plan your project's development and
to record releases:
Line 9: Line 10:
 * '''Series:''' parallel lines of development within your project, working towards a major release.
 * '''Series goals:''' bugs or blueprints that will be fixed in a particular series.
 * '''Milestones:''' points in the development of a series, such as future minor releases or release candidates.
 * '''Releases:''' once a milestone results in a release of your software, you can turn it into a release in Launchpad.
 * '''Series:''' parallel lines of development within your project, working
towards a major release.
 * '''Series goals:''' bugs or blueprints that will be fixed in a particular
series.
 * '''Milestones:''' points in the development of a series, such as future
minor releases or release candidates.
 * '''Releases:''' once a milestone results in a release of your software,
you can turn it into a release in Launchpad.
Line 14: Line 19:
Launchpad doesn't impose a particular workflow on your project, so you can pick and choose how you use Launchpad's development and release planning. Launchpad doesn't impose a particular workflow on your project, so you can
pick and choose how you use Launchpad's development and release planning.
Line 18: Line 24:
When we think of the way a project organises itself, there are major lines of development from which releases are "cut". Typically these lines of development represent: When we think of the way a project organises itself, there are major lines of
development from which releases are "cut". Typically these lines of
development represent:
Line 20: Line 28:
 * '''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.  * '''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 22: Line 34:
 * '''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.  * '''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 24: Line 38:
 * '''Obsolete branches:''' for major release versions that are now out of date and no longer updated. It's likely that work no longer happens on these branches.  * '''Obsolete branches:''' for major release versions that are now out of
date and no longer updated. It's likely that work no longer happens on these
branches.
Line 26: Line 42:
We call each of these "major" lines of development a "series" because they represent a series of releases of the same major version. We call each of these "major" lines of development a "series" because they
represent a series of releases of the same major version.
Line 38: Line 55:
For an example, take a look at the [[https://launchpad.net/bzr|Bazaar]] project. There you'll see a number of series each with their related milestones and releases. For an example, take a look at the [[https://launchpad.net/bzr|Bazaar]]
project. There you'll see a number of series each with their related
milestones and releases.
Line 43: Line 62:
To create a series, provided you're either the project's owner or driver, click ```Register a series``` in the ```Series and milestones``` section of your project overview page. To create a series, provided you're either the project's owner or driver,
click ```Register a series``` in the ```Series and milestones``` section of
your project overview page.
Line 45: Line 66:
Different projects have different ideas of what a series represents and what naming convention to use. 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, they branch it to create 2.19, the new "trunk". Different projects have different ideas of what a series represents and what
naming convention to use. 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, they branch it to create 2.19, the new "trunk".
Line 49: Line 74:
You can name and use your series however you choose in Launchpad. However, for convention, we encourage you to call your project's development focus "trunk" and to use that same branch for development over time. When creating a new stable series, such as the line of development for your next major release, we suggest you: You can name and use your series however you choose in Launchpad. However, for
convention, we encourage you to call your project's development focus "trunk"
and to use that same branch for development over time. When creating a new
stable series, such as the line of development for your next major release, we
suggest you:
Line 56: Line 85:
This ensures that people who create a checkout of "trunk" always get the tip of your development, rather than discovering later on that it has turned into a stable release. This ensures that people who create a checkout of "trunk" always get the tip
of your development, rather than discovering later on that it has turned into
a stable release.
Line 58: Line 89:
You can tell people the purpose of each series with a short description. Bazaar's ```bzr.dev``` series overview page shows that it's described as "...the development mainline where new releases are published". You can tell people the purpose of each series with a short description.
Bazaar's ```bzr.dev``` series overview page shows that it's described as
"...the development mainline where new releases are published".
Line 63: Line 96:
As series tend to represent planned releases, it's useful to target bugs and blueprints to particular series. These are called series goals and must be approved by either the project or that series' release manager. As series tend to represent planned releases, it's useful to target bugs and
blueprints to particular series. These are called series goals and must be
approved by either the project or that series' release manager.
Line 65: Line 100:
[[https://edge.launchpad.net/beeseek/|BeeSeek]] is a project to create an open source peer to peer search engine. BeeSeek's drivers have accepted [[https://bugs.launchpad.net/beeseek/+bug/182821|bug 182821]] as affecting two of their series, [[https://edge.launchpad.net/beeseek/hive|Hive]] and [[https://launchpad.net/beeseek/honeybee|Honeybee]]. [[https://edge.launchpad.net/beeseek/|BeeSeek]] is a project to create an open
source peer to peer search engine. BeeSeek's drivers have accepted
[[https://bugs.launchpad.net/beeseek/+bug/182821|bug 182821]] as affecting two
of their series, [[https://edge.launchpad.net/beeseek/hive|Hive]] and
[[https://launchpad.net/beeseek/honeybee|Honeybee]].
Line 67: Line 106:
Anyone can nominate a bug or blueprint as affecting a particular series with the ```Nominate for release``` link. However, only the relevant driver can accept it as series goal. Anyone can nominate a bug or blueprint as affecting a particular series with
the ```Nominate for release``` link. However, only the relevant driver can
accept it as series goal.
Line 72: Line 113:
As both these series represent separate code bases, implementing a bug fix in them may fall to different people. It's also likely that the bug will have a different implementation status and importance in each series. As you can see in the BeeSeek example, Launchpad tracks separate importance, status and assignee information for the same bug in each series. BeeSeek have chosen not to fix the bug in their Hive series but Andrea Corbellini has already committed a fix in the Honeybee series. As both these series represent separate code bases, implementing a bug fix in
them may fall to different people. It's also likely that the bug will have a
different implementation status and importance in each series. As you can see
in the BeeSeek example, Launchpad tracks separate importance, status and
assignee information for the same bug in each series. BeeSeek have chosen not
to fix the bug in their Hive series but Andrea Corbellini has already
committed a fix in the Honeybee series.
Line 74: Line 121:
Launchpad excels at tracking how an individual bug affects different communities and contexts; we'll see more of that later in this guide. Launchpad excels at tracking how an individual bug affects different
communities and contexts; we'll see more of that later in this guide.
Line 85: Line 133:
They're an ideal lightweight way to group a number of bugs and blueprints, optionally targeted to a particular date. Just like series themselves, you can target individual bugs and blueprints to a particular milestone. However, they differ in a couple of important ways: They're an ideal lightweight way to group a number of bugs and blueprints,
optionally targeted to a particular date. Just like series themselves, you can
target individual bugs and blueprints to a particular milestone. However, they
differ in a couple of important ways:
Line 87: Line 138:
 * only a project owner, series release manager or bug contact can target a bug or blueprint to a milestone: other people cannot nominate a chunk work for a milestone
 * milestones exist within a series -- your project must have at least one series.
 * only a project owner, series release manager or bug contact can target a
bug or blueprint to a milestone: other people cannot nominate a chunk work
for a milestone
 * milestones exist within a series -- your project must have at least one
series.
Line 90: Line 144:
Milestones naturally lead to releases. Once the software associated with the milestone is released, you can turn that milestone into a release in Launchpad. Milestones naturally lead to releases. Once the software associated with the
milestone is released, you can turn that milestone into a release in
Launchpad.
Line 94: Line 150:
Launchpad helps you to record and publicise the actual details of your release, such as its release date and changelog. Each release shows up in the timeline on your project's Launchpad home page, providing a historical record of what happened and when. Launchpad helps you to record and publicise the actual details of your
release, such as its release date and changelog. Each release shows up in the
timeline on your project's Launchpad home page, providing a historical record
of what happened and when.
Line 98: Line 157:
Making those files available for [[Projects/FileDownloads|download]] is what we'll look at next. Making those files available for [[Projects/FileDownloads|download]] is what
we'll look at next.

Launchpad Help > Projects > Series, milestones and releases

Overview

Let's look at how you can use Launchpad to plan your project's development and to record releases:

  • Series: parallel lines of development within your project, working towards a major release.

  • Series goals: bugs or blueprints that will be fixed in a particular series.

  • Milestones: points in the development of a series, such as future minor releases or release candidates.

  • Releases: once a milestone results in a release of your software, you can turn it into a release in Launchpad.

Launchpad doesn't impose a particular workflow on your project, so you can pick and choose how you use Launchpad's development and release planning.

Series

When we think of the way a project organises itself, there are major lines of development from which releases are "cut". Typically these lines of development 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 updated. It's likely that work no longer happens on these branches.

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

In Launchpad, each series behaves almost like a sub-project, having its own:

  • branches of code
  • bugs marked as affecting that series
  • bugs and blueprints proposed as goals for the series
  • translation effort
  • milestones - specific points in the roadmap leading to a release
  • releases
  • release manager.

For an example, take a look at the Bazaar project. There you'll see a number of series each with their related milestones and releases.

Creating series

To create a series, provided you're either the project's owner or driver, click Register a series in the Series and milestones section of your project overview page.

Different projects have different ideas of what a series represents and what naming convention to use. 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, they branch it to create 2.19, the new "trunk".

Sometimes, projects also call the trunk "MAIN", a term from the days of CVS.

You can name and use your series however you choose in Launchpad. However, for convention, we encourage you to call your project's development focus "trunk" and to use that same branch for development over time. When creating a new stable series, such as the line of development for your next major release, we suggest you:

  • branch from trunk
  • create the new series
  • register your new branch in Launchpad and link it to the new series
  • leave trunk in place for ongoing development.

This ensures that people who create a checkout of "trunk" always get the tip of your development, rather than discovering later on that it has turned into a stable release.

You can tell people the purpose of each series with a short description. Bazaar's bzr.dev series overview page shows that it's described as "...the development mainline where new releases are published".

Series goals

As series tend to represent planned releases, it's useful to target bugs and blueprints to particular series. These are called series goals and must be approved by either the project or that series' release manager.

BeeSeek is a project to create an open source peer to peer search engine. BeeSeek's drivers have accepted bug 182821 as affecting two of their series, Hive and Honeybee.

Anyone can nominate a bug or blueprint as affecting a particular series with the Nominate for release link. However, only the relevant driver can accept it as series goal.

beeseek-bug.png

Series goal for Hive and Honeybee in BeeSeek

As both these series represent separate code bases, implementing a bug fix in them may fall to different people. It's also likely that the bug will have a different implementation status and importance in each series. As you can see in the BeeSeek example, Launchpad tracks separate importance, status and assignee information for the same bug in each series. BeeSeek have chosen not to fix the bug in their Hive series but Andrea Corbellini has already committed a fix in the Honeybee series.

Launchpad excels at tracking how an individual bug affects different communities and contexts; we'll see more of that later in this guide.

Milestones

Milestones are specific points during the life of a series, such as:

  • beta tests
  • release candidates
  • minor and major point releases.

They're an ideal lightweight way to group a number of bugs and blueprints, optionally targeted to a particular date. Just like series themselves, you can target individual bugs and blueprints to a particular milestone. However, they differ in a couple of important ways:

  • only a project owner, series release manager or bug contact can target a bug or blueprint to a milestone: other people cannot nominate a chunk work for a milestone
  • milestones exist within a series -- your project must have at least one series.

Milestones naturally lead to releases. Once the software associated with the milestone is released, you can turn that milestone into a release in Launchpad.

Releases

Launchpad helps you to record and publicise the actual details of your release, such as its release date and changelog. Each release shows up in the timeline on your project's Launchpad home page, providing a historical record of what happened and when.

Next step

Making those files available for download is what we'll look at next.

< Registering a project

Publishing files for download >

Projects/SeriesMilestonesReleases (last edited 2012-07-11 16:11:30 by pool-108-28-25-212)