You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Mark R. Diggory" <md...@latte.harvard.edu> on 2004/01/29 18:48:21 UTC
[math] Details on Cutting the release
I'd like us to get together a solid documentation fragment so that
releases are cut using the same approach each time.
Proposal for Current Release Cutting Strategy:
1.) Maven should be used to generate releases in the various required
formats.
2.) We should define or override clear maven goals within the
math/maven.xml to produce the release and clearly document the process
for the Release Manager.
3.) We should start using version numbers and documenting when we cut in
the project.xml and cvs tagging.
commons-math-0.1-dev is sort of a weak and inadequate starting point,
recommend we change it to "commons-math-1.0" and start incrementing.
Once we establish our release date, I don't see how [dev|alpha|beta|rcX]
designations are really going to help us this early on. Lets just cut it
and then deal with real issues that arise afterward. If our users really
want testing versions, we can start using them.
4.) We should outline the appropriate contents and directory structuring
for a release.The current configuration I've worked on produces the
following:
*binary releases* (tar.gz and zip)
> Archive: commons-math-0.1-dev.zip
> Length Date Time Name
> -------- ---- ---- ----
> 0 01-29-04 09:31 commons-math-0.1-dev/
> 11358 01-29-04 09:31 commons-math-0.1-dev/LICENSE.txt
> 0 01-29-04 09:31 commons-math-0.1-dev/docs/
> 0 01-29-04 09:31 commons-math-0.1-dev/docs/clover/
> ...
> 6103 01-29-04 09:31 commons-math-0.1-dev/docs/apidocs/
> ...
> 124140 01-29-04 09:31 commons-math-0.1-dev/commons-math-0.1-dev.jar
> 110531 01-29-04 09:31 commons-math-0.1-dev/commons-beanutils-1.5.jar
> 165119 01-29-04 09:31 commons-math-0.1-dev/commons-collections-2.1.jar
> 72176 01-29-04 09:31 commons-math-0.1-dev/commons-discovery-20030211.213356.jar
> 31605 01-29-04 09:31 commons-math-0.1-dev/commons-logging-1.0.3.jar
> 169763 01-29-04 09:31 commons-math-0.1-dev/commons-lang-2.0.jar
*src release* (tar.gz and zip)
> Archive: commons-math-0.1-dev-src.zip
> Length Date Time Name
> -------- ---- ---- ----
> 0 01-29-04 09:31 commons-math-0.1-dev/
> 0 01-29-04 09:31 commons-math-0.1-dev/src/
> 282 01-29-04 09:31 commons-math-0.1-dev/src/conf/MANIFEST.MF
> 0 01-29-04 09:31 commons-math-0.1-dev/src/test/...
...
> 0 01-29-04 09:31 commons-math-0.1-dev/src/java/...
...
> 0 01-29-04 09:31 commons-math-0.1-dev/src/experimental/...
... (actually think this shouldn't be here).
> 0 01-29-04 09:31 commons-math-0.1-dev/src/conf/
> 370 01-29-04 09:31 commons-math-0.1-dev/maven.xml
> 4692 01-29-04 09:31 commons-math-0.1-dev/project.xml
This project.xml is the one with the dependencies resolved to a version.
> 801 01-29-04 09:31 commons-math-0.1-dev/project.properties
> 11358 01-29-04 09:31 commons-math-0.1-dev/LICENSE.txt
> 6635 01-29-04 09:31 commons-math-0.1-dev/build.xml
This build.xml is generated off the above project.xml, so its
dependencies are resolved as well.
*jar release* (jar)
> Archive: commons-math-0.1-dev.jar
> Length Date Time Name
> -------- ---- ---- ----
> 0 01-29-04 09:30 META-INF/
> 423 01-29-04 09:30 META-INF/MANIFEST.MF
> 11358 01-29-04 09:23 META-INF/LICENSE.txt
> 0 01-17-04 15:05 org/
> 0 01-17-04 15:05 org/apache/
> 0 01-17-04 15:05 org/apache/commons/
> 0 01-17-04 15:05 org/apache/commons/math/
> 0 01-17-04 15:05 org/apache/commons/math/analysis/
> 0 01-29-04 09:24 org/apache/commons/math/complex/
> 0 01-28-04 16:32 org/apache/commons/math/distribution/
> 0 01-28-04 16:32 org/apache/commons/math/linear/
> 0 01-17-04 15:05 org/apache/commons/math/random/
> 0 01-28-04 16:32 org/apache/commons/math/stat/
> 0 01-17-04 15:05 org/apache/commons/math/stat/univariate/
> 0 01-17-04 15:05 org/apache/commons/math/stat/univariate/rank/
> 0 01-17-04 15:05 org/apache/commons/math/stat/univariate/moment/
> 0 01-17-04 15:05 org/apache/commons/math/stat/univariate/summary/
> 0 01-17-04 15:05 org/apache/commons/math/special/
> 0 01-17-04 15:05 org/apache/commons/math/util/
> 1609 01-29-04 09:24 org/apache/commons/math/analysis/BisectionSolver.class
> 3033 01-29-04 09:24 org/apache/commons/math/analysis/UnivariateRealSolverImpl.class
> 799 01-29-04 09:24 org/apache/commons/math/analysis/UnivariateRealSolver.class
> 247 01-29-04 09:24 org/apache/commons/math/analysis/UnivariateRealFunction.class
...
So the jar has no tests and no experimental code within it.
Any Comments?
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Details on Cutting the release
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Al Chou wrote:
> I guess the jar file distribution is for when you need to grab a library you
> already know you depend on, without getting anything else -- say, when you're
> installing an already-written app that depends on a jar, and that jar didn't
> come with the app. That makes sense to me, I've certainly needed that sort of
> packaging enough times myself!
>
>
> Al
>
Exactly, and we will be providing documentation and source from the
JUnit tests and examples in the tar.gz/zip distributions so that if a
user is doing initial learning, exploration and development, then they
have a strong example base to work with. And still, in this case, we
want to keep that source separate from the packaged math jar provided or
built in those distributions.
Maybe, we can provide some "applets" that execute in the User Manual
documentation such that the user can see and play around with live
examples while reading the documentation on them. Any thoughts?
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Details on Cutting the release
Posted by Al Chou <ho...@yahoo.com>.
--- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
> Al Chou wrote:
>
> > --- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
> > [deletia]
> >
> >
> >>*jar release* (jar)
> >>
> >>
> >>>Archive: commons-math-0.1-dev.jar
> >
> > [deletia]
> >
> >
> >>So the jar has no tests and no experimental code within it.
> >>
> >>
> >>Any Comments?
> >>
> >>-Mark
> >
> >
> >
> > Sorry to chime in so late, but my preference would be to include the tests
> no
> > matter which release package it is. They serve as examples of using the
> code,
> > even if one decided to suspect them as a validation of the correctness of
> the
> > code (which is up to the individual user). I know that may seem to
> hybridize
> > all release packages, but if it were standard to include test source with
> all
> > our release packages, it maybe wouldn't seem like they were hybrids as much
> as
> > it would be just an additional form of documentation.
> >
> >
> > Al
>
> Yes Al, we should plan to include the src/test java files into the
> source and binary tar/zip distributions. But (IMHO) the
> commons-math-1.0.jar itself is strictly just the api. I think this is
> the standard way that commons projects are packaged.
>
> -Mark
I guess the jar file distribution is for when you need to grab a library you
already know you depend on, without getting anything else -- say, when you're
installing an already-written app that depends on a jar, and that jar didn't
come with the app. That makes sense to me, I've certainly needed that sort of
packaging enough times myself!
Al
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Details on Cutting the release
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Al Chou wrote:
> --- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
> [deletia]
>
>
>>*jar release* (jar)
>>
>>
>>>Archive: commons-math-0.1-dev.jar
>
> [deletia]
>
>
>>So the jar has no tests and no experimental code within it.
>>
>>
>>Any Comments?
>>
>>-Mark
>
>
>
> Sorry to chime in so late, but my preference would be to include the tests no
> matter which release package it is. They serve as examples of using the code,
> even if one decided to suspect them as a validation of the correctness of the
> code (which is up to the individual user). I know that may seem to hybridize
> all release packages, but if it were standard to include test source with all
> our release packages, it maybe wouldn't seem like they were hybrids as much as
> it would be just an additional form of documentation.
>
>
> Al
Yes Al, we should plan to include the src/test java files into the
source and binary tar/zip distributions. But (IMHO) the
commons-math-1.0.jar itself is strictly just the api. I think this is
the standard way that commons projects are packaged.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Details on Cutting the release
Posted by Al Chou <ho...@yahoo.com>.
--- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
[deletia]
> *jar release* (jar)
>
> > Archive: commons-math-0.1-dev.jar
[deletia]
> So the jar has no tests and no experimental code within it.
>
>
> Any Comments?
>
> -Mark
Sorry to chime in so late, but my preference would be to include the tests no
matter which release package it is. They serve as examples of using the code,
even if one decided to suspect them as a validation of the correctness of the
code (which is up to the individual user). I know that may seem to hybridize
all release packages, but if it were standard to include test source with all
our release packages, it maybe wouldn't seem like they were hybrids as much as
it would be just an additional form of documentation.
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Details on Cutting the release
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Phil Steitz wrote:
> --- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
>>commons-math-0.1-dev is sort of a weak and inadequate starting point,
>>recommend we change it to "commons-math-1.0" and start incrementing.
>>Once we establish our release date, I don't see how [dev|alpha|beta|rcX]
>>designations are really going to help us this early on. Lets just cut it
>>and then deal with real issues that arise afterward. If our users really
>>want testing versions, we can start using them.
>
>
> I think that we should release a 0.1 "soon." I will post a straw man
> release plan / updated task list this evening. I think 0.1 is a good
> starting point.
I just think 0.1 sounds like we havn't done anything yet, which couldn't
farther from the truth.
>
>
>>
>>4.) We should outline the appropriate contents and directory structuring
>>for a release.The current configuration I've worked on produces the
>>following:
>>
>>
>>*binary releases* (tar.gz and zip)
>>
>>
>>>Archive: commons-math-0.1-dev.zip
>>> Length Date Time Name
>>> -------- ---- ---- ----
>>> 0 01-29-04 09:31 commons-math-0.1-dev/
>>> 11358 01-29-04 09:31 commons-math-0.1-dev/LICENSE.txt
>>> 0 01-29-04 09:31 commons-math-0.1-dev/docs/
>>> 0 01-29-04 09:31 commons-math-0.1-dev/docs/clover/
>>
>> > ...
>>
>>> 6103 01-29-04 09:31 commons-math-0.1-dev/docs/apidocs/
>>>...
>>> 124140 01-29-04 09:31
>>
>>commons-math-0.1-dev/commons-math-0.1-dev.jar
>>
>>> 110531 01-29-04 09:31
>>
>>commons-math-0.1-dev/commons-beanutils-1.5.jar
>>
>>> 165119 01-29-04 09:31
>>
>>commons-math-0.1-dev/commons-collections-2.1.jar
>>
>>> 72176 01-29-04 09:31
>>
>>commons-math-0.1-dev/commons-discovery-20030211.213356.jar
>>
>>> 31605 01-29-04 09:31
>>
>>commons-math-0.1-dev/commons-logging-1.0.3.jar
>>
>>> 169763 01-29-04 09:31 commons-math-0.1-dev/commons-lang-2.0.jar
>>
>
> I don't know if bundling the dependent jars is the best idea. What is the
> most prevalent practice among other commons components? In any case, it
> might be better to bundle them in a separate /lib directory.
>
I was approaching it as such:
1.) If you really want to use "math" and don't want to "chase
dependencies", then the binary distribution (with dependency jars
included) is the way to go. (they can go in a lib idr if its more to
peoples liking).
2.) If you want to build it yourself the src distributions with their
included build.xml scripts is the way to go. (The build script will
download the dependencies from ibiblio for you).
3.) If you just want it as a component jar and deal with dependencies
yourself, just grab the jar and go (either from ibiblio, or any apache
mirror via the java-repository directory).
Three distributions, three different purposes. So if we want to have a
binary archive with just the math jar and javadoc (maybe a build.xml
script to download the jars) then we can add that to the list.
It would be good to cook up README.txt or INSTALL.txt instructions on
each too.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Details on Cutting the release
Posted by Phil Steitz <st...@yahoo.com>.
--- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
> I'd like us to get together a solid documentation fragment so that
> releases are cut using the same approach each time.
>
> Proposal for Current Release Cutting Strategy:
>
> 1.) Maven should be used to generate releases in the various required
> formats.
>
> 2.) We should define or override clear maven goals within the
> math/maven.xml to produce the release and clearly document the process
> for the Release Manager.
>
> 3.) We should start using version numbers and documenting when we cut in
> the project.xml and cvs tagging.
>
> commons-math-0.1-dev is sort of a weak and inadequate starting point,
> recommend we change it to "commons-math-1.0" and start incrementing.
> Once we establish our release date, I don't see how [dev|alpha|beta|rcX]
> designations are really going to help us this early on. Lets just cut it
> and then deal with real issues that arise afterward. If our users really
> want testing versions, we can start using them.
I think that we should release a 0.1 "soon." I will post a straw man
release plan / updated task list this evening. I think 0.1 is a good
starting point.
>
>
> 4.) We should outline the appropriate contents and directory structuring
> for a release.The current configuration I've worked on produces the
> following:
>
>
> *binary releases* (tar.gz and zip)
>
> > Archive: commons-math-0.1-dev.zip
> > Length Date Time Name
> > -------- ---- ---- ----
> > 0 01-29-04 09:31 commons-math-0.1-dev/
> > 11358 01-29-04 09:31 commons-math-0.1-dev/LICENSE.txt
> > 0 01-29-04 09:31 commons-math-0.1-dev/docs/
> > 0 01-29-04 09:31 commons-math-0.1-dev/docs/clover/
> > ...
> > 6103 01-29-04 09:31 commons-math-0.1-dev/docs/apidocs/
> > ...
> > 124140 01-29-04 09:31
> commons-math-0.1-dev/commons-math-0.1-dev.jar
> > 110531 01-29-04 09:31
> commons-math-0.1-dev/commons-beanutils-1.5.jar
> > 165119 01-29-04 09:31
> commons-math-0.1-dev/commons-collections-2.1.jar
> > 72176 01-29-04 09:31
> commons-math-0.1-dev/commons-discovery-20030211.213356.jar
> > 31605 01-29-04 09:31
> commons-math-0.1-dev/commons-logging-1.0.3.jar
> > 169763 01-29-04 09:31 commons-math-0.1-dev/commons-lang-2.0.jar
>
I don't know if bundling the dependent jars is the best idea. What is the
most prevalent practice among other commons components? In any case, it
might be better to bundle them in a separate /lib directory.
>
> *src release* (tar.gz and zip)
>
> > Archive: commons-math-0.1-dev-src.zip
> > Length Date Time Name
> > -------- ---- ---- ----
> > 0 01-29-04 09:31 commons-math-0.1-dev/
> > 0 01-29-04 09:31 commons-math-0.1-dev/src/
> > 282 01-29-04 09:31 commons-math-0.1-dev/src/conf/MANIFEST.MF
> > 0 01-29-04 09:31 commons-math-0.1-dev/src/test/...
> ...
> > 0 01-29-04 09:31 commons-math-0.1-dev/src/java/...
> ...
> > 0 01-29-04 09:31 commons-math-0.1-dev/src/experimental/...
> ... (actually think this shouldn't be here).
>
> > 0 01-29-04 09:31 commons-math-0.1-dev/src/conf/
> > 370 01-29-04 09:31 commons-math-0.1-dev/maven.xml
> > 4692 01-29-04 09:31 commons-math-0.1-dev/project.xml
>
> This project.xml is the one with the dependencies resolved to a version.
>
> > 801 01-29-04 09:31 commons-math-0.1-dev/project.properties
> > 11358 01-29-04 09:31 commons-math-0.1-dev/LICENSE.txt
> > 6635 01-29-04 09:31 commons-math-0.1-dev/build.xml
>
> This build.xml is generated off the above project.xml, so its
> dependencies are resolved as well.
>
>
>
> *jar release* (jar)
>
> > Archive: commons-math-0.1-dev.jar
> > Length Date Time Name
> > -------- ---- ---- ----
> > 0 01-29-04 09:30 META-INF/
> > 423 01-29-04 09:30 META-INF/MANIFEST.MF
> > 11358 01-29-04 09:23 META-INF/LICENSE.txt
> > 0 01-17-04 15:05 org/
> > 0 01-17-04 15:05 org/apache/
> > 0 01-17-04 15:05 org/apache/commons/
> > 0 01-17-04 15:05 org/apache/commons/math/
> > 0 01-17-04 15:05 org/apache/commons/math/analysis/
> > 0 01-29-04 09:24 org/apache/commons/math/complex/
> > 0 01-28-04 16:32 org/apache/commons/math/distribution/
> > 0 01-28-04 16:32 org/apache/commons/math/linear/
> > 0 01-17-04 15:05 org/apache/commons/math/random/
> > 0 01-28-04 16:32 org/apache/commons/math/stat/
> > 0 01-17-04 15:05 org/apache/commons/math/stat/univariate/
> > 0 01-17-04 15:05
> org/apache/commons/math/stat/univariate/rank/
> > 0 01-17-04 15:05
> org/apache/commons/math/stat/univariate/moment/
> > 0 01-17-04 15:05
> org/apache/commons/math/stat/univariate/summary/
> > 0 01-17-04 15:05 org/apache/commons/math/special/
> > 0 01-17-04 15:05 org/apache/commons/math/util/
> > 1609 01-29-04 09:24
> org/apache/commons/math/analysis/BisectionSolver.class
> > 3033 01-29-04 09:24
> org/apache/commons/math/analysis/UnivariateRealSolverImpl.class
> > 799 01-29-04 09:24
> org/apache/commons/math/analysis/UnivariateRealSolver.class
> > 247 01-29-04 09:24
> org/apache/commons/math/analysis/UnivariateRealFunction.class
> ...
>
> So the jar has no tests and no experimental code within it.
>
>
>
> Any Comments?
>
> -Mark
>
> --
> Mark Diggory
> Software Developer
> Harvard MIT Data Center
> http://www.hmdc.harvard.edu
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org