harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [general] M3 milestone discussion
Date Fri, 24 Aug 2007 10:53:01 GMT
I personally somehow concur with Salikh's opinion. As Tim mentioned,
"the problems with getting a JCK license to certify official releases
have been well-documented". We have to face the situation, and we
probably want to start releasing "official" Harmony with a new and
formal and stable versioning scheme till we get a certified version
released. It can be started from 0.1, for example, or something like
that.

The official release can have a little longer release cycle, say, 3
months, to give us more time to enhance Harmony in both robustness,
performance and new features, i.e., to make it worth a release. I
really think it's time to consider providing Harmony package to
various Linux distributions. If we think it's  not mature enough for
distribution packages, we can call it 0.1alpha.

Thanks,
xiaofeng

On 8/23/07, Salikh Zakirov <salikh@gmail.com> wrote:
> Tim Ellison wrote:
> > Agreed, and the problems with getting a JCK license to certify official
> > releases have been well-documented.  We want to release a Java
> > implementation, not something that is not quite Java.
>
> Somehow I cannot understand how the "official" status of the release
> is related to the "certification with JCK" status.
> I understand the desire of releasing certified 1.0 (or is it 5.0?)
> version, however, I cannot see why alpha or beta releases should
> not be done before JCK certification.
>
> Careful reading of Apache licensing policy [1] says that this is the
> sort of decision done by PMC. However, it also says that anything
> with non-released status should not be advertised outside of the mailing
> list (i.e. on the web site), and therefore, should not be packaged
> for end-users (i.e. Debian or Gentoo packages).
>
> Thus, I understand what you are saying as "we should not yet advertise ourselves
> outside of our mailing list". This is exactly opposite of my opinion, that
> Harmony project need to start recruiting beta-testers (alpha-testers?)
> in a wider audience.
>
> This is also in contradiction with the fact of stable builds being announced
> on the web site.
>
> What I am suggesting, is
> (1) come up with a stable versioning scheme (FWIW, M1 has happened to DRLVM twice already),
> (2) decide if the current status is alpha or beta
> (3) release the next stable snapshot officially (following all the requirements [1])
>     with either of alpha and beta status
>     and all necessary notices about non-compatibility and non-certified status.
> (4) remove the "they are not official releases of the Apache Harmony project" notices
>     from the download page.
> (5) and finally, encourage (rather than discourage) including these alpha releases
>     to "unstable" areas of the popular Linux distributions
>
> PMC may as well disagree with this suggestion, but it would be nice to hear where exactly
> disagreement lies:
>
> (a) if Harmony project should not seek for a wider tester base?
> (b) if Harmony project should not encourage packaging for distributions?
> (c) if Harmony project should not do uncertified alpha and beta releases?
>
> [1] http://www.apache.org/dev/release.html#what
>
> quote from Apache Releases FAQ [1]
> > During the process of developing software and preparing a release,
> > various packages are made available to the developer community for testing purposes.
> > Do not include any links on the project website that might encourage non-developers
> > to download and use nightly builds, snapshots, release candidates, or any other
> > similar package. The only people who are supposed to know about such packages are
> > the people following the dev list (or searching its archives) and thus aware
> > of the conditions placed on the package. If you find that the general public
> > are downloading such test packages, then remove them.
>
>
>
>


-- 
http://xiao-feng.blogspot.com

Mime
View raw message