You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Danny Angus <da...@thought.co.uk> on 2002/01/10 12:49:59 UTC
Version numbers...
I'd like to propose that we use a version number system like that used by
bugzilla, namely that the head of CVS have an even minor number and
milestone releases have the opposite, in addition "nightly" releases would
have the same version number as the current CVS.
Thus CVS is currently 2.0a2, when we make a milestone release it would be
released as 2.0a3 and CVS would advance to 2.0a4, that way there would be no
confusion between bugs reported against released versions and bugs reported
against nightly builds/cvs.
this is the explanation from bugzilla..
"We only place tarballs of even-numbered minor versions on the FTP server.
The installed version on bugzilla.mozilla.org (and the most recent CVS
version, which is a slightly newer version than the installed version)
always have an odd-numbered minor version. If you want to get exactly the
code that mozilla.org is running, you're out of luck (they make internal
patches just like everyone else), but you can get pretty close by using CVS,
and the minor version number will be odd. If you want a more stable release,
you can use a tarball, and the minor version number will be even. "
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Version numbers...
Posted by Peter Donald <pe...@apache.org>.
On Sat, 12 Jan 2002 11:47, Darrell DeBoer wrote:
> Actually (after voting +1), an alternative would be to just have the
> version number in CVS something like "2.0a2-unreleased" (or even
> "2.0a2-cvs"), and simply remove the "unreleased"/"cvs" extension when the
> build is formally released. This would prevent any confusion which may
> arise from builds going "missing" (ie "where can I download 2.0a3 ?" ).
+1
> Even better would be to attach a unique number to each commit - where I
> work we have a changelog file, which *must* be updated with every CVS
> commit, including providing a new "build" number and a log a what was
> changed. The change log ( a simple XML file) is then parsed by an Ant task
> during the build, and the constants file is updated with the build number.
> This way, we can tell *exactly* which build was being used for a bug
> report.
>
> I'd be happy to get a commit-changelog file working, as long as committers
> are willing to update it when they make changes. The way I work is I to
> enter my changes into the changelog once I'm happy with everything, and
> then Cut&Paste that entry as my CVS commit log message. This gives us a
> nice historical view of the CVS commit log messages, from within the CVS
> tree.
Alternatively you could go the opposite way. I am not sure if I fully got
this working but in tthe phoenix project I used a task to generate a XML
ChangeLog based on the CVS logs. However instead of directly using this I
tended to clean/simply/munge the changes into the real ChangeLog.
--
Cheers,
Pete
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Version numbers...
Posted by Darrell DeBoer <li...@bigdaz.com>.
> I'd be happy to get a commit-changelog file working, as long as committers
> are willing to update it when they make changes. The way I work is I to
> enter my changes into the changelog once I'm happy with everything, and
then
> Cut&Paste that entry as my CVS commit log message. This gives us a nice
> historical view of the CVS commit log messages, from within the CVS tree.
Just to clarify, here's what my last commit could look like:
------------------------------------------------------------------------
<changeLog>
<version number="2.0a3">
<commit number="xxx">
- Library upgrade
- Upgraded Avalon,Pheonix and Cornerstone libraries to more recent
versions.
- Removed deprecated usage of o.a.a.phoenix.Service from
MailServer and UsersStore interfaces.
- Changed o.a.j.BaseConnectionHandler to use new Logging framework,
so
that it can work with new version of Cornerstone. Also needed
slight mods
to extensions to BaseConnectionHandler (NNTPHandler,
AbstractJdbcUsersRepository,
UsersLDAPRepository)
- Now get heaps of deprecation warnings for usage of
o.a.log.Loggable
- Source tree is no longer copied to build/src before compiling,
source files are compiled directly from src/java
</commit>
<commit number="...">
....
</commit>
</release>
</changeLog>
---------------------------------------------------------------------------
The actual commit message could be more formatted XML, but then it's a pain
to write...
When James was built from this commit, it would then run with a message
like:
James 2.0a3 (build xxx)
or something like that.
What do you reckon?
ciao
daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Version numbers...
Posted by Darrell DeBoer <li...@bigdaz.com>.
> we do have a changelog .. its in xdocs and is "built" with the rest of the
> docs .. http://jakarta.apache.org/james/changelog.html
> I like Pete's idea of generating a changelog from the cvs logs,
> even if you then have to cut and paste the non-trivial changes into the
> actual changelog doc it'd save a heap of effort.
Sorry, "changeLog" was probably the wrong name. I meant a Commit log, which
included a unique number for each CVS commit. This could be sanitised to
create sensible release notes (including a change-log).
The main thing I'd like is unique build numbers, so that we can tell
*exactly* what code is running. I'm sure this can be automated with some
tricky CVS integration, but having played with the CVS mailer before, I'm
not too keen on delving into those nasty Perl scripts again. ;) I'd be just
as happy with a rule that said - "when you commit changes to CVS, you bump
the build number in file XXX". (Or run some Ant target, which itself bumps
the number). I know this enforces discipline on the developers, but I don't
know of any other simple way to do it.
ciao
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Version numbers...
Posted by Danny Angus <da...@thought.co.uk>.
>
> I'd be happy to get a commit-changelog file working, as long as committers
> are willing to update it when they make changes. The way I work is I to
> enter my changes into the changelog once I'm happy with
> everything, and then
> Cut&Paste that entry as my CVS commit log message. This gives us a nice
> historical view of the CVS commit log messages, from within the CVS tree.
>
we do have a changelog .. its in xdocs and is "built" with the rest of the
docs .. http://jakarta.apache.org/james/changelog.html
I like Pete's idea of generating a changelog from the cvs logs,
even if you then have to cut and paste the non-trivial changes into the
actual changelog doc it'd save a heap of effort.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Version numbers...
Posted by Darrell DeBoer <li...@bigdaz.com>.
G'day
Actually (after voting +1), an alternative would be to just have the version
number in CVS something like "2.0a2-unreleased" (or even "2.0a2-cvs"), and
simply remove the "unreleased"/"cvs" extension when the build is formally
released. This would prevent any confusion which may arise from builds going
"missing" (ie "where can I download 2.0a3 ?" ).
Even better would be to attach a unique number to each commit - where I work
we have a changelog file, which *must* be updated with every CVS commit,
including providing a new "build" number and a log a what was changed. The
change log ( a simple XML file) is then parsed by an Ant task during the
build, and the constants file is updated with the build number. This way, we
can tell *exactly* which build was being used for a bug report.
I'd be happy to get a commit-changelog file working, as long as committers
are willing to update it when they make changes. The way I work is I to
enter my changes into the changelog once I'm happy with everything, and then
Cut&Paste that entry as my CVS commit log message. This gives us a nice
historical view of the CVS commit log messages, from within the CVS tree.
ciao
Daz
----- Original Message -----
From: "Danny Angus" <da...@thought.co.uk>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Saturday, January 12, 2002 2:57 AM
Subject: RE: Version numbers...
> Should we vote on this?
>
> > -----Original Message-----
> > From: Danny Angus [mailto:danny@thought.co.uk]
> > Sent: Thursday, January 10, 2002 11:50 AM
> > To: James Developers List
> > Subject: Version numbers...
> >
> >
> > I'd like to propose that we use a version number system like that used
by
> > bugzilla, namely that the head of CVS have an even minor number and
> > milestone releases have the opposite, in addition "nightly" releases
would
> > have the same version number as the current CVS.
> >
> > Thus CVS is currently 2.0a2, when we make a milestone release it would
be
> > released as 2.0a3 and CVS would advance to 2.0a4, that way there
> > would be no
> > confusion between bugs reported against released versions and
> > bugs reported
> > against nightly builds/cvs.
> >
> > this is the explanation from bugzilla..
> >
> > "We only place tarballs of even-numbered minor versions on the FTP
server.
> > The installed version on bugzilla.mozilla.org (and the most recent CVS
> > version, which is a slightly newer version than the installed version)
> > always have an odd-numbered minor version. If you want to get exactly
the
> > code that mozilla.org is running, you're out of luck (they make internal
> > patches just like everyone else), but you can get pretty close by
> > using CVS,
> > and the minor version number will be odd. If you want a more
> > stable release,
> > you can use a tarball, and the minor version number will be even. "
> >
> > d.
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Starting James without -jar
Posted by Jeff Dillon <je...@jeffdillon.com>.
> However, the latest versions of Phoenix (the app server
> on which James runs) have the facility to run as an NT service, using the
> Java Wrapper project (http://wrapper.sourceforge.net).
Cool. That looks like a better solution than what I was trying to do.
> You'll need to give us a little more time to get this working, but if you
> can wait (or help :), it might save you a bit of grief.
I'll work on getting James to run as an NT service with the java wrapper
program instead. Thanks.
Jeff
Jeff Dillon
http://www.jeffdillon.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Starting James without -jar
Posted by Darrell DeBoer <li...@bigdaz.com>.
Hi Jeff
> I'm trying to write a utility to run James as a Windows 2k service and I
> need to figure out how to run james without the -jar option.
I don't know how to help with your specific query (I can run James
without -jar, but only by having Intellij specify the *entire* classpath on
the command-line). However, the latest versions of Phoenix (the app server
on which James runs) have the facility to run as an NT service, using the
Java Wrapper project (http://wrapper.sourceforge.net).
You'll need to give us a little more time to get this working, but if you
can wait (or help :), it might save you a bit of grief.
ciao
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: catch all...
Posted by Serge Knystautas <se...@lokitech.com>.
Yeah, just do this....
<mailet match="HostIsLocal" class="Forward">
<forwardto>mypostmasteraddress@mydomain.com</forwardto>
</mailet>
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
----- Original Message -----
From: "Danny Angus" <da...@thought.co.uk>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Saturday, January 12, 2002 8:23 AM
Subject: RE: catch all...
> If you're using version 2+ you can use the redirect mailet in place of the
> ToProcessor one
> (if you're not you can still use it if you get it from the v2 source, it
is
> compatible with v1 too)
> in this config block:
>
> <mailet match="HostIsLocal" class="ToProcessor">
> <processor>error</processor>
> </mailet>
>
> to configure the style of the notification to better suit your ambitions,
> see:
> http://jakarta.apache.org/james/configuration_v2_0.html (its a big one at
> the bottom of the page)
> and if you're interested in extending this mailet to provide custom
> functionality see also:
>
http://jakarta.apache.org/james/javadocs/org/apache/james/transport/mailets/
> Redirect.html
>
> d.
>
> > -----Original Message-----
> > From: Keith Chew SL [mailto:keithcsl@ihug.co.nz]
> > Sent: Saturday, January 12, 2002 1:30 PM
> > To: James Developers List
> > Subject: RE: catch all...
> >
> >
> >
> > I just tried the notification to postmaster on error. It's not
> > exactly what
> > I had in mind, but it'll do just fine.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: catch all...
Posted by Keith Chew SL <ke...@ihug.co.nz>.
Great! That was exactly what I was looking for!
Thanks Danny.
Keith
> -----Original Message-----
> From: Danny Angus [mailto:danny@thought.co.uk]
> Sent: Sunday, 13 January 2002 2:24 a.m.
> To: James Developers List
> Subject: RE: catch all...
>
>
> If you're using version 2+ you can use the redirect mailet in place of the
> ToProcessor one
> (if you're not you can still use it if you get it from the v2
> source, it is
> compatible with v1 too)
> in this config block:
>
> <mailet match="HostIsLocal" class="ToProcessor">
> <processor>error</processor>
> </mailet>
>
> to configure the style of the notification to better suit your ambitions,
> see:
> http://jakarta.apache.org/james/configuration_v2_0.html (its a big one at
> the bottom of the page)
> and if you're interested in extending this mailet to provide custom
> functionality see also:
> http://jakarta.apache.org/james/javadocs/org/apache/james/transpor
t/mailets/
Redirect.html
d.
> -----Original Message-----
> From: Keith Chew SL [mailto:keithcsl@ihug.co.nz]
> Sent: Saturday, January 12, 2002 1:30 PM
> To: James Developers List
> Subject: RE: catch all...
>
>
>
> I just tried the notification to postmaster on error. It's not
> exactly what
> I had in mind, but it'll do just fine.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: catch all...
Posted by Danny Angus <da...@thought.co.uk>.
If you're using version 2+ you can use the redirect mailet in place of the
ToProcessor one
(if you're not you can still use it if you get it from the v2 source, it is
compatible with v1 too)
in this config block:
<mailet match="HostIsLocal" class="ToProcessor">
<processor>error</processor>
</mailet>
to configure the style of the notification to better suit your ambitions,
see:
http://jakarta.apache.org/james/configuration_v2_0.html (its a big one at
the bottom of the page)
and if you're interested in extending this mailet to provide custom
functionality see also:
http://jakarta.apache.org/james/javadocs/org/apache/james/transport/mailets/
Redirect.html
d.
> -----Original Message-----
> From: Keith Chew SL [mailto:keithcsl@ihug.co.nz]
> Sent: Saturday, January 12, 2002 1:30 PM
> To: James Developers List
> Subject: RE: catch all...
>
>
>
> I just tried the notification to postmaster on error. It's not
> exactly what
> I had in mind, but it'll do just fine.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: catch all...
Posted by Keith Chew SL <ke...@ihug.co.nz>.
I just tried the notification to postmaster on error. It's not exactly what
I had in mind, but it'll do just fine.
Thanks!
Keith
> -----Original Message-----
> From: Danny Angus [mailto:danny@thought.co.uk]
> Sent: Sunday, 13 January 2002 12:33 a.m.
> To: James Developers List
> Subject: RE: catch all...
>
>
> Yes indeed, and this is exactly what happens in the default
> configuration ..
> undelivered email is treated as an error, and the error mailet
> process logs
> the message and can be set to notify the postmaster, or anyone else.
> d.
>
> > -----Original Message-----
> > From: Keith Chew SL [mailto:keithcsl@ihug.co.nz]
> > Sent: Friday, January 11, 2002 10:41 PM
> > To: James Developers List
> > Subject: catch all...
> >
> >
> > Hi
> >
> > Is it possible to have a catch all for unsubscribed users in a domain?
> >
> > Example
> >
> > James Server is hosting for domain abc.com.
> > I would like any unsubscribed user , eg blah-blah@abc.com to go to
> > global@abc.com
> >
> > This is so that if someone tries to send a query to infomation@abc.com
> > instead of info@abc.com, I'll still get it.
> >
> > Keith
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: catch all...
Posted by Danny Angus <da...@thought.co.uk>.
Yes indeed, and this is exactly what happens in the default configuration ..
undelivered email is treated as an error, and the error mailet process logs
the message and can be set to notify the postmaster, or anyone else.
d.
> -----Original Message-----
> From: Keith Chew SL [mailto:keithcsl@ihug.co.nz]
> Sent: Friday, January 11, 2002 10:41 PM
> To: James Developers List
> Subject: catch all...
>
>
> Hi
>
> Is it possible to have a catch all for unsubscribed users in a domain?
>
> Example
>
> James Server is hosting for domain abc.com.
> I would like any unsubscribed user , eg blah-blah@abc.com to go to
> global@abc.com
>
> This is so that if someone tries to send a query to infomation@abc.com
> instead of info@abc.com, I'll still get it.
>
> Keith
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
catch all...
Posted by Keith Chew SL <ke...@ihug.co.nz>.
Hi
Is it possible to have a catch all for unsubscribed users in a domain?
Example
James Server is hosting for domain abc.com.
I would like any unsubscribed user , eg blah-blah@abc.com to go to
global@abc.com
This is so that if someone tries to send a query to infomation@abc.com
instead of info@abc.com, I'll still get it.
Keith
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Starting James without -jar
Posted by Jeff Dillon <je...@jeffdillon.com>.
Hello-
I'm trying to write a utility to run James as a Windows 2k service and I
need to figure out how to run james without the -jar option.
I looked at Tomcat and it does it with...
%_RUNJAVA%
%CATALINA_OPTS% -Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA
_HOME%" org.apache.catalina.startup.Bootstrap %1 %2 %3 %4 %5 %6 %7 %8 %9
I am trying to do a similar thing with James like...
set PHOENIX_HOME=%~dp0 // sets to current directory
java -Djava.ext.dirs=%PHOENIX_HOME%\lib -Djava.class.path=%PHOENIX_HOME%\pho
enix-loader.jar org.apache.avalon.phoenix.launcher.Main
I keep getting class not found errors even though the classes that it
complains about exist in the jars found in the lib directory. Perhaps I
don't understand the java.ext.dirs setting, I'm not sure.
Thanks
Jeff Dillon
http://www.jeffdillon.com
----- Original Message -----
From: "Danny Angus" <da...@thought.co.uk>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Friday, January 11, 2002 1:52 PM
Subject: RE: Version numbers...
> I'm kinda forging ahead on that basis, but silence from *everyone* is just
a
> little off-putting ;-)
>
> > -----Original Message-----
> > From: Harmeet [mailto:harmeet@kodemuse.com]
> > Sent: Friday, January 11, 2002 7:13 PM
> > To: James Developers List
> > Subject: Re: Version numbers...
> >
> >
> > From: "Danny Angus" <da...@thought.co.uk>
> > > Should we vote on this?
> >
> > Silence to me is implicit 'I am ok with it'. at least a 0 or +1.
> > For me it is +1.
> >
> > Harmeet
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Version numbers...
Posted by Danny Angus <da...@thought.co.uk>.
I'm kinda forging ahead on that basis, but silence from *everyone* is just a
little off-putting ;-)
> -----Original Message-----
> From: Harmeet [mailto:harmeet@kodemuse.com]
> Sent: Friday, January 11, 2002 7:13 PM
> To: James Developers List
> Subject: Re: Version numbers...
>
>
> From: "Danny Angus" <da...@thought.co.uk>
> > Should we vote on this?
>
> Silence to me is implicit 'I am ok with it'. at least a 0 or +1.
> For me it is +1.
>
> Harmeet
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Version numbers...
Posted by Harmeet <ha...@kodemuse.com>.
From: "Danny Angus" <da...@thought.co.uk>
> Should we vote on this?
Silence to me is implicit 'I am ok with it'. at least a 0 or +1.
For me it is +1.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Version numbers...
Posted by Darrell DeBoer <li...@bigdaz.com>.
+1
----- Original Message -----
From: "Danny Angus" <da...@thought.co.uk>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Saturday, January 12, 2002 2:57 AM
Subject: RE: Version numbers...
> Should we vote on this?
>
> > -----Original Message-----
> > From: Danny Angus [mailto:danny@thought.co.uk]
> > Sent: Thursday, January 10, 2002 11:50 AM
> > To: James Developers List
> > Subject: Version numbers...
> >
> >
> > I'd like to propose that we use a version number system like that used
by
> > bugzilla, namely that the head of CVS have an even minor number and
> > milestone releases have the opposite, in addition "nightly" releases
would
> > have the same version number as the current CVS.
> >
> > Thus CVS is currently 2.0a2, when we make a milestone release it would
be
> > released as 2.0a3 and CVS would advance to 2.0a4, that way there
> > would be no
> > confusion between bugs reported against released versions and
> > bugs reported
> > against nightly builds/cvs.
> >
> > this is the explanation from bugzilla..
> >
> > "We only place tarballs of even-numbered minor versions on the FTP
server.
> > The installed version on bugzilla.mozilla.org (and the most recent CVS
> > version, which is a slightly newer version than the installed version)
> > always have an odd-numbered minor version. If you want to get exactly
the
> > code that mozilla.org is running, you're out of luck (they make internal
> > patches just like everyone else), but you can get pretty close by
> > using CVS,
> > and the minor version number will be odd. If you want a more
> > stable release,
> > you can use a tarball, and the minor version number will be even. "
> >
> > d.
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Version numbers...
Posted by Serge Knystautas <se...@lokitech.com>.
+1 :)
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
----- Original Message -----
From: "Danny Angus" <da...@thought.co.uk>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Friday, January 11, 2002 11:57 AM
Subject: RE: Version numbers...
> Should we vote on this?
>
> > -----Original Message-----
> > From: Danny Angus [mailto:danny@thought.co.uk]
> > Sent: Thursday, January 10, 2002 11:50 AM
> > To: James Developers List
> > Subject: Version numbers...
> >
> >
> > I'd like to propose that we use a version number system like that used
by
> > bugzilla, namely that the head of CVS have an even minor number and
> > milestone releases have the opposite, in addition "nightly" releases
would
> > have the same version number as the current CVS.
> >
> > Thus CVS is currently 2.0a2, when we make a milestone release it would
be
> > released as 2.0a3 and CVS would advance to 2.0a4, that way there
> > would be no
> > confusion between bugs reported against released versions and
> > bugs reported
> > against nightly builds/cvs.
> >
> > this is the explanation from bugzilla..
> >
> > "We only place tarballs of even-numbered minor versions on the FTP
server.
> > The installed version on bugzilla.mozilla.org (and the most recent CVS
> > version, which is a slightly newer version than the installed version)
> > always have an odd-numbered minor version. If you want to get exactly
the
> > code that mozilla.org is running, you're out of luck (they make internal
> > patches just like everyone else), but you can get pretty close by
> > using CVS,
> > and the minor version number will be odd. If you want a more
> > stable release,
> > you can use a tarball, and the minor version number will be even. "
> >
> > d.
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Version numbers...
Posted by Danny Angus <da...@thought.co.uk>.
Should we vote on this?
> -----Original Message-----
> From: Danny Angus [mailto:danny@thought.co.uk]
> Sent: Thursday, January 10, 2002 11:50 AM
> To: James Developers List
> Subject: Version numbers...
>
>
> I'd like to propose that we use a version number system like that used by
> bugzilla, namely that the head of CVS have an even minor number and
> milestone releases have the opposite, in addition "nightly" releases would
> have the same version number as the current CVS.
>
> Thus CVS is currently 2.0a2, when we make a milestone release it would be
> released as 2.0a3 and CVS would advance to 2.0a4, that way there
> would be no
> confusion between bugs reported against released versions and
> bugs reported
> against nightly builds/cvs.
>
> this is the explanation from bugzilla..
>
> "We only place tarballs of even-numbered minor versions on the FTP server.
> The installed version on bugzilla.mozilla.org (and the most recent CVS
> version, which is a slightly newer version than the installed version)
> always have an odd-numbered minor version. If you want to get exactly the
> code that mozilla.org is running, you're out of luck (they make internal
> patches just like everyone else), but you can get pretty close by
> using CVS,
> and the minor version number will be odd. If you want a more
> stable release,
> you can use a tarball, and the minor version number will be even. "
>
> d.
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>