Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#118 closed defect (released)

Release version 1.0.0

Reported by: richard Owned by: olly
Priority: highest Milestone:
Component: Meta-Bug Version: SVN trunk
Severity: normal Keywords:
Cc: Blocked By: #38, #86, #115, #117, #119, #121, #122, #125, #126, #131, #137, #142, #144
Blocking: Operating System: All

Description

This bug is to track features and bug fixes which are needed for version 1.0. The idea is that it should depend on bugs which need to be resolved before 1.0.

The aim is to get 1.0 released as soon as possible - if at all possible, in April 2007. Therefore, we need to stop writing new code to implement features very soon, and just focus on stabilising and testing what we have.

1.0 doesn't need to come with any new guarantees on API stability (though people may expect it to, so we should be clear in the release notes about what we are guaranteeing).

Change History (36)

comment:1 Changed 11 years ago by richard

  • Blocked By 117 added

comment:2 Changed 11 years ago by richard

  • Blocked By 38 added

comment:3 Changed 11 years ago by richard

  • Blocked By 22 added

comment:4 Changed 11 years ago by richard

  • Blocked By 113 added

comment:5 Changed 11 years ago by richard

  • Blocked By 46 added

comment:6 Changed 11 years ago by richard

  • Blocked By 44 added

comment:7 Changed 11 years ago by richard

  • Blocked By 63 added

comment:8 Changed 11 years ago by richard

  • Blocked By 86 added

comment:9 Changed 11 years ago by richard

  • Blocked By 115 added

comment:10 Changed 11 years ago by richard

  • Blocked By 119 added

comment:11 Changed 11 years ago by olly

  • Status changed from new to assigned

I wonder if we should promise no incompatible API or ABI changes within a 1.0.x, etc. If we're forced to change something incompatibly, we can just bump to 1.1.x (or not backport a fix if we've already release 1.1.0). I think packagers would be happier with fewer library version bumps. Thoughts?

comment:12 Changed 11 years ago by richard

I think having no incompatible API or ABI changes unless the minor (or major) version number changes is the right thing: I think that's what people tend to expect the version numbers to mean.

The thing to be clear about is how long we're likely to support the 1.0.x release series. I would think it's unlikely to be longer than a year at most, given the number of things we've got pending for adding to the tree at the moment: we'll probably want to move to 1.1 releases withing a few months of releasing 1.0, if we're keeping API and ABI stable for 1.0.

This does mean that we'll end up maintianing a stable branch and a "development" branch almost all the time. How much work has it been to maintain the 0.9 branch? Do we need to assign a separate maintainer for the "stable" branch? (I could do one, and you could do the other, if that would help.)

comment:13 Changed 11 years ago by olly

  • Blocked By 46 removed

comment:14 Changed 11 years ago by richard

  • Blocked By 44 removed

comment:15 Changed 11 years ago by olly

Backporting fixes to 0.9 hasn't been too bad, though I feel 0.9 had rather a gap with no activity. But looking back at the release dates that doesn't really seem to be the case (there's a long gap over last summer, but similar length gaps in the past too, and I was away for 5 weeks). There is an issue of how much was in each release though which is harder to judge with a quick grep.

A separate maintainer might be useful. It would be good to sort out the various scripts so I'm not a common bottleneck for as many things (though it's not been a problem so far really).

But I think I'd rather have this discussion after 1.0 is out really.

comment:16 Changed 11 years ago by richard

  • Blocked By 121 added

comment:17 Changed 11 years ago by richard

  • Blocked By 122 added

comment:18 Changed 11 years ago by olly

  • Component changed from Other to Meta-Bug
  • rep_platform changed from PC to All

Added a category "Meta-Bug"!

comment:19 Changed 11 years ago by richard

  • Blocked By 125 added

comment:20 Changed 11 years ago by richard

  • Blocked By 126 added

comment:21 Changed 11 years ago by richard

  • Blocked By 123 added

comment:22 Changed 11 years ago by richard

  • Blocked By 123 removed

comment:23 Changed 11 years ago by olly

  • Blocked By 63 removed

comment:24 Changed 11 years ago by richard

  • Blocked By 131 added

comment:25 Changed 10 years ago by richard

  • Blocked By 138 added

comment:26 Changed 10 years ago by olly

  • Blocked By 137 added

comment:27 Changed 10 years ago by olly

  • Priority changed from normal to highest
  • Summary changed from Release version 1.0 to Release version 1.0.0

comment:28 Changed 10 years ago by richard

  • Blocked By 142 added

comment:29 Changed 10 years ago by olly

  • Blocked By 141 added

comment:30 Changed 10 years ago by olly

  • Blocked By 141 removed

comment:31 Changed 10 years ago by richard

  • Blocked By 138 removed

comment:32 Changed 10 years ago by richard

  • Blocked By 144 added

comment:33 Changed 10 years ago by olly

  • Blocked By 113 removed

comment:34 Changed 10 years ago by olly

  • Blocked By 22 removed

comment:35 Changed 10 years ago by olly

  • Resolution set to fixed
  • Status changed from assigned to closed

1.0.0 will be released shortly, so closing this.

comment:36 Changed 10 years ago by olly

  • Operating System set to All
  • Resolution changed from fixed to released
Note: See TracTickets for help on using tickets.