Diff for "Projects/SeriesMilestonesReleases/Draft"

Not logged in - Log In / Register

Differences between revisions 1 and 7 (spanning 6 versions)
Revision 1 as of 2008-03-13 22:34:28
Size: 5321
Editor: 77-100-239-119
Comment:
Revision 7 as of 2008-03-18 08:54:58
Size: 8449
Editor: 77-100-239-119
Comment: Improved initial "releases" description
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
 * '''Releases:''' previous releases within a series.  * '''Releases:''' a record of releases that you've made from a series.
Line 28: Line 28:
In Launchpad, each series almost behaves like a sub-project within the project as it can have: In Launchpad, each series behaves almost like a sub-project, having its own:
Line 32: Line 32:
 * its own translation effort
Line 34: Line 33:
 * milestones specific points in the roadmap
 * releases.
 * translation effort
* milestones - specific points in the roadmap
 * releases
 * driver - in effect a release manager
.
Line 42: Line 43:
A project usually has multiple lines of development, particularly if it has previously produced stable releases. In the Bazaar example you can see: Here you can see some of the different lines of development from the Bazaar project:
Line 48: Line 49:
== Naming a series == == Creating series ==

To create a series, provided you're either the project's owner or driver, click ```Register a series``` in the ```Actions``` menu.
Line 50: Line 53:
It's up to the project what each series represents and what the naming convention is. 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". It's up to each project what a series represents and what naming convention they 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 54: Line 57:
For convention, we encourage projects to call their development focus "trunk" and to use that same branch for development 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 later become a stable series. 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: 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 later become a stable series.
Line 61: Line 64:
== Series and code == Over time, a great deal of useful public information about the history of a project becomes associated with its series. That's why, right now, the only way to delete a project series is to [https://answers.launchpad.net/launchpad/+addquestion make a request with the Launchpad admins].
Line 63: Line 66:
If you have code registered in Launchpad against your current development focus, anyone can create their own Bazaar branch of it using just a few keystrokes. == Series goals ==
Line 65: Line 68:
There's more about using Launchpad and Bazaar together later in this guide. However, for now fire up your terminal and try: 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' driver.
Line 67: Line 70:
{{{
$ bzr branch lp:pyroom
Branched 41 revision(s).
}}}
[https://edge.launchpad.net/beeseek/ BeeSeek] is a project to create an open source peer to peer search engine. BeeSeek's drivers have marked [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 72: Line 72:
This will create a local branch on your machine of the Pyroom text editor's current development focus. Replace ```pyroom``` with the Launchpad name of any project that has code registered against a current development focus in Launchpad. ||<tablestyle="font-size: 0.8em; width:30%; background:#F1F1ED; margin: 1em 1em 1em 0;" style="padding:0.5em;">attachment:beeseek-bug.png||
||<style="text-align: center;">'''Series goal for Hive and Honeybee in BeeSeek'''||
Line 74: Line 75:
If you want to get the code for a different series, simply specify the series name after the project name: As you can see, this bug has a separate importance, status and assignee in each series. Launchpad excels at tracking how an individual bug affects different communities and contexts; we'll see more of that later.
Line 76: Line 77:
{{{
$ bzr branch lp:pyroom/0.1
Branched 26 revision(s).
}}}

We'll take a look at using series with each of Launchpad's applications later in the guide, including marking bugs and blueprints as series goals.
Anyone can nominate a bug or blueprint as affecting a particular series with the ```Nominate for release``` link in the ```Actions``` menu. However, only the relevant driver can accept it as series goal.
Line 84: Line 80:

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, driver 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 the series - your project must have at least one series.

This is [https://launchpad.net/awn/+milestone/0.4 Avant Window Navigator's 0.4] milestone.

||<tablestyle="font-size: 0.8em; width:30%; background:#F1F1ED; margin: 1em 1em 1em 0;" style="padding:0.5em;">attachment:awn-04.png||
||<style="text-align: center;">'''Milestone 0.4 for Avant Window Navigator'''||

As you can see, milestones are a really simple way of organising work. Other than a brief description of the milestone's purpose, there's a list of the six blueprints and twenty three bugs targeted to it. Now, everyone working towards AWN 0.4 knows what the release will look like and has the opportunity to volunteer to take some of the work.

Creating a milestone takes no more than clicking ```Add milestone``` in the ```Actions``` menu for the relevant series. Once the milestone's complete, uncheck ```Active``` on its ```Modify milestone details``` page. Once deactivated, the milestone no longer appears on your project's overview or milestone pages but it still accessible through its URL.

= Releases =

||<tablestyle="float: right; font-size: 0.8em; width:30%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;">attachment:register-a-release.png||
||<style="text-align: center;">'''Registering a release'''||

While series and milestones help you to plan work that may become a release, they're less useful once you've actually made that release.

You can record the important information about a release, such as its changelog. By registering your releases in Launchpad you can build a public history of your project and make its binaries available for [:Projects/Downloads:download].

= Next steps =

Now that we've seen how series, milestones and releases fit together, let's [:Projects/Downloads:publish your project's files].

DRAFT: this page is a work in progress. Please [:Feedback:seek further help] or check the [:TitleIndex:wiki index] for a complete page on this topic.

ContentsBRTableOfContents

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: a record of releases that you've made from a series.

Launchpad doesn't impose a particular workflow on your project, so how and whether you use these depends on what value you feel they'll bring.

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
  • releases
  • driver - in effect a release manager.

Let's take a look at the [https://launchpad.net/bzr Bazaar] project as an example.

attachment:bzr-timeline.png

Series in the Bazaar project

Here you can see some of the different lines of development from the Bazaar project:

  • bzr.dev: the current line of active development and source of snapshot test releases for the next stable version.

  • 1.3: the latest stable version recommended to new users.

  • 1.2, 1.1, 1.0: previous lines of development that produced releases.

Creating series

To create a series, provided you're either the project's owner or driver, click Register a series in the Actions menu.

It's up to each project what a series represents and what naming convention they 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.

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: 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 later become a stable series.

When you register a series, the description you give it tells other people what your intentions are. If we look at Bazaar's bzr.dev series overview page we can see that it's described as "...the development mainline where new releases are published".

attachment:bzr-sev-series-overviewtimeline.png

The bzr.dev series overview

Over time, a great deal of useful public information about the history of a project becomes associated with its series. That's why, right now, the only way to delete a project series is to [https://answers.launchpad.net/launchpad/+addquestion make a request with the Launchpad admins].

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' driver.

[https://edge.launchpad.net/beeseek/ BeeSeek] is a project to create an open source peer to peer search engine. BeeSeek's drivers have marked [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].

attachment:beeseek-bug.png

Series goal for Hive and Honeybee in BeeSeek

As you can see, this bug has a separate importance, status and assignee in each series. Launchpad excels at tracking how an individual bug affects different communities and contexts; we'll see more of that later.

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

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, driver 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 the series - your project must have at least one series.

This is [https://launchpad.net/awn/+milestone/0.4 Avant Window Navigator's 0.4] milestone.

attachment:awn-04.png

Milestone 0.4 for Avant Window Navigator

As you can see, milestones are a really simple way of organising work. Other than a brief description of the milestone's purpose, there's a list of the six blueprints and twenty three bugs targeted to it. Now, everyone working towards AWN 0.4 knows what the release will look like and has the opportunity to volunteer to take some of the work.

Creating a milestone takes no more than clicking Add milestone in the Actions menu for the relevant series. Once the milestone's complete, uncheck Active on its Modify milestone details page. Once deactivated, the milestone no longer appears on your project's overview or milestone pages but it still accessible through its URL.

Releases

attachment:register-a-release.png

Registering a release

While series and milestones help you to plan work that may become a release, they're less useful once you've actually made that release.

You can record the important information about a release, such as its changelog. By registering your releases in Launchpad you can build a public history of your project and make its binaries available for [:Projects/Downloads:download].

Next steps

Now that we've seen how series, milestones and releases fit together, let's [:Projects/Downloads:publish your project's files].

Projects/SeriesMilestonesReleases/Draft (last edited 2008-06-17 14:21:16 by localhost)