X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fintro.xml;h=fdd3271753d00288653fc7913f3f93ecc9333141;hb=f5605a5a2ea4a4707c9bec48048d730f0f56dae2;hp=d4b6a1241f5a2e15b52e3887d1a0448aa3b4c457;hpb=0065d5ab628975892cea1ec7303f968c3338cbe1;p=ghc-hetmet.git
diff --git a/docs/users_guide/intro.xml b/docs/users_guide/intro.xml
index d4b6a12..fdd3271 100644
--- a/docs/users_guide/intro.xml
+++ b/docs/users_guide/intro.xml
@@ -223,114 +223,31 @@
reporting bugs
- Glasgow Haskell is a changing system so there are sure to be
- bugs in it.
+
+ Glasgow Haskell is a changing system so there are sure to be
+ bugs in it. If you find one, please see
+ this wiki page
+ for information on how to report it.
+
- To report a bug, either:
-
-
-
- Preferred: Create
- a new bug, and enter your bug report. You can also
- search the bug database here to make sure your bug hasn't already
- been reported (if it has, it might still help to add information
- from your experience to the existing report).
-
-
- Bug reports can also be emailed to
- glasgow-haskell-bugs@haskell.org.
-
-
-
-
- How do I tell if I should report my bug?
-
- Take a look at the FAQ and , which will give you some guidance as to
- whether the behaviour you're seeing is really a bug or
- not.
-
- If it is a bug, then it might have been reported before:
- try searching on the bug tracker,
- and failing that, try Google.
-
- If in doubt, just report it.
-
-
-
- What to put in a bug report
- bug reportscontents
-
- The name of the bug-reporting game is: facts, facts,
- facts. Don't omit them because “Oh, they won't be
- interested…”
-
-
-
- What kind of machine are you running on, and exactly
- what version of the operating system are you using? (on a
- Unix system, uname -a or cat
- /etc/motd will show the desired information.) In
- the bug tracker, this information can be given in the
- “Architecture” and “Operating
- system” fields.
-
-
-
- What version of GCC are you using? gcc -v will tell you.
-
-
-
- Run the sequence of compiles/runs that caused the
- offending behaviour, cut-and-paste the whole session into
- the bug report. We'd prefer to see the whole thing.
-
-
-
- Add the -v flag when running GHC, so we can see exactly
- what was run, what versions of things you have, etc.
-
-
-
- What is the program behaviour that is wrong, in your
- opinion?
-
-
-
- If practical, please attach or send enough source
- files for us to duplicate the problem.
-
-
-
- If you are a Hero and track down the problem in the
- compilation-system sources, please send us patches (either
- darcs send, plain patches, or just whole
- files if you prefer).
-
-
-
GHC version numbering policy
version, of ghc
- As of GHC version 6.0, we have adopted the following policy
+ As of GHC version 6.8, we have adopted the following policy
for numbering GHC versions:
Stable Releases
- These are numbered x.y.z, where
- y is even, and
- z is the patchlevel number (the trailing
- .z can be omitted if z
- is zero). Patchlevels are bug-fix releases only, and never
+ Stable branches are numbered x.y, where
+ y is even.
+ Releases on the stable branch x.y are numbered x.y.z, where
+ z (>= 1) is the patchlevel number.
+ Patchlevels are bug-fix releases only, and never
change the programmer interface to any system-supplied code.
However, if you install a new patchlevel over an old one you
will need to recompile any code that was compiled against the
@@ -341,8 +258,8 @@
x.y.z
is the integer xyy (if
y is a single digit, then a leading zero
- is added, so for example in version 6.2 of GHC,
- __GLASGOW_HASKELL__==602).
+ is added, so for example in version 6.8.2 of GHC we would have
+ __GLASGOW_HASKELL__==608).
__GLASGOW_HASKELL__
@@ -350,28 +267,52 @@
- Snapshots/unstable releases
+ Stable snapshots
+
+
+ We may make snapshot releases of the current
+ stable branch available for download, and the latest sources are available from the darcs repositories.
+
+
+ Stable snapshot releases are named
+ x.y.z.YYYYMMDD.
+ where YYYYMMDD is the date of the sources
+ from which the snapshot was built, and x.y.z+1 is the next release to be made on that branch.
+ For example, 6.8.1.20040225 would be a
+ snapshot of the 6.8 branch during the development
+ of 6.8.2.
+
+ The value of __GLASGOW_HASKELL__
+ for a snapshot release is the integer
+ xyy. You should never write any
+ conditional code which tests for this value, however: since
+ interfaces change on a day-to-day basis, and we don't have
+ finer granularity in the values of
+ __GLASGOW_HASKELL__, you should only
+ conditionally compile using predicates which test whether
+ __GLASGOW_HASKELL__ is equal to, later
+ than, or earlier than a given major release.
+
+ __GLASGOW_HASKELL__
+
+
+
+
+
+ Unstable snapshots
- We may make snapshot releases of the current
- development sources from time to time, and the current
- sources are always available via the CVS repository (see the
- GHC web
- site for details).
-
- Snapshot releases are named
- x.y.YYYYMMDD
- where YYYYMMDD is the date of the sources
- from which the snapshot was built. In theory, you can check
- out the exact same sources from the CVS repository using
- this date.
-
- If y is odd, then this is a
- snapshot of the CVS HEAD (the main development branch). If
- y is even, then it is a snapshot
- of the stable branch between patchlevel releases. For
- example, 6.3.20040225 would be a snapshot
- of the HEAD, but 6.2.20040225 would be a
- snapshot of the 6.2 branch.
+
+ We may make snapshot releases of the
+ HEAD available for download, and the latest sources are available from the darcs repositories.
+
+
+ Unstable snapshot releases are named
+ x.y.YYYYMMDD.
+ where YYYYMMDD is the date of the sources
+ from which the snapshot was built.
+ For example, 6.7.20040225 would be a
+ snapshot of the HEAD before the creation of the
+ 6.8 branch.
The value of __GLASGOW_HASKELL__
for a snapshot release is the integer