Bug 429 - Release 0.8.4 tracker bug
Summary: Release 0.8.4 tracker bug
Status: RESOLVED WONTFIX
Alias: None
Product: STSF
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All All
: highest blocker
Assignee: Alexander Gelfenbain
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 404 409 410 426
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-07 21:42 UTC by Roland Mainz
Modified: 2008-01-22 17:37 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Roland Mainz 2004-04-07 21:42:56 UTC
Tracking bug for the upcoming release <xxx>. We should only release when all
blockers for this bug have been resolved..

Alexander:
1. What's the "version" of the next release ? "0.8", "0.8.1" or "0.9" ?
2. Should the release have any nickname (e.g. "smaug"
(http://www.glyphweb.com/arda/s/smaug.html - a good source for trademark-free
names), "angel", "satan", "painmonster", etc.) ?
Comment 1 Roland Mainz 2004-04-09 17:33:41 UTC
Setting release name to 0.8.4 for now...

Alexander:
Is there any release date for "0.8.4" in sight yet ?
Comment 2 Alexander Gelfenbain 2004-04-12 19:50:18 UTC
Here is my theory about release numbers. Well, it's actually not a theory but
rather the way I've been numbering STSF releases:

Major.Minor.Update.Build.Protocol_Version

Build and Protocol_Version are internal to ST numbers with very limited visibility.

"Update" is something that can be bumped up without giving it too much thought,
for example when we need to mark fixing some important bug.

"Minor" is bumped up only when something major happens. It needs to be
incremented when an incompatible version of the protocol or binary files is
introduced.

"Major" is 0 until release 1.0 is available.

So next releases will be 0.9, 0.10, 0.11, etc... until we decide to do a 1.0
release. 


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.