This is *not* a release candidate... this is just for people to review
to see what problems they can see now.
A couple of additional changes would have been in a real release, including
- a note of the version number in CHANGES.txt, and perhaps some
release-notes type of stuff in there as well
- a bump of version number in build.xml
- tags, and all that jazz
I think we should try to make a real release candidate by the end of next week.
> On 12/7/06, Yonik Seeley <[hidden email]> wrote:
> > I've gone through the process of making release artifacts and put them here:
> > http://people.apache.org/~yonik/solr/test_release/ > >
> > This is *not* a release candidate... this is just for people to review
> > to see what problems they can see now.
> Is there anything in particular you would like reviewed? I don't know
> much about apache release policies or licenses so I'm not sure how to
> help out here.
Could you go through the process of trying to verify the signatures?
That's something that might turn out different than if I did it myself
(since it's my keys).
Example: gpg --verify apache-solr-1.1.0-incubating.tgz.asc
gpg: Signature made Fri Dec 8 04:22:19 2006 CET using DSA key ID 0AFCEE7C
gpg: Good signature from "Yonik Seeley <[hidden email]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: E404 B4CF 10D8 F153 04F7 651C B83E A82A 0AFC EE7C
On 12/7/06, Yonik Seeley <[hidden email]> wrote:
> I think we should try to make a real release candidate by the end of next week.
I also think we should start trying to make regular releases, or at
least release more often.
So don't worry if your favorite feature or cleanup isn't in this
release, it can go in the next.
One if the biggest reasons for this release is that we need to show we
can do releases to get out of the incubator.
So if you have a favorite feature/fix you would like to be in this
release, let's try to get it committed in the next few days.
Some incubator people have been recommending release notes.
It made me think about the discussion we had about calling out non
back compatible stuff in CHANGES.txt, and makes me think that should
be the release notes.
Put a higher level section at the top, with potentially a little more
general info and how to migrade, and all the individual changes below.
Some projects do it like this.