Versioning, contents of STATUS and CHANGES files

[Rodent of Unusual Size <Ke...@Golux.Com>]

-----BEGIN PGP SIGNED MESSAGE-----

<hat type="mentor" state"on">

Is there anything in the code that tells someone using a copy
built from Subversion that it isn't a formally released version?
If there isn't, there needs to be one.  As an example, the HTTP Server
project sets the server version to something like "2.0.54-dev"
while 2.0.54 is in development, then sets that to "2.0.54" and
builds the release, and then sets the version in the code to
"2.0.55-dev".  This allows people to know from *exactly* where in the
release sequence their version came, and whether it was released or
something still in alpha/beta status.

In looking through the sources for Derby, I don't see anything like
that.  I recall that there's an issue with the version being embedded
in the database (or something like that), but the *code* version and
the *database* version aren't identical, just related.  If I'm missing
something, just ignore me.

Have there been no changes to the code since the release of 10.0.2.1?
If there have been, they should be getting recorded in the trunk/CHANGES
file, at the top, under a heading such as

Changes in Derby 10.0.2.2-dev

(or whatever version number is being used/embedded to identify
the code as alpha/beta).  At the 10.0.2.2 release, that gets altered
to 'Changes with 10.0.2.2' and a new 'Changes with 10.0.2.3-dev'
heading is started above it.  Otherwise the CHANGES file won't change
except at releases, which is a disservice to people observing or
getting involved in the development mid-stream.

When I took a look at the trunk/STATUS file this morning, I noticed
two things.  Firstly, that the formatting and wrapping was a bit off;
I fixed that.  Secondly, that the file appears to contain a lot of
unnecessary or redundant info.  It's intended to touch the high points,
detailing what currently needs work and what items are under discussion
(or have been committed/vetoed after being discussed) since the last
release.  Once the next release goes out the door, a lot of that gets
cleaned up so that the file refers strictly to the current state of
the code.  The STATUS file's purpose in not to provide exhaustive status
nor to include all past history.  It's appropriate to include *some*
environmental status while we're in the incubator, but if/when we graduate
it should be reduced to just development/technical status, and project
meta-data (guidelines, history, et cetera) should be moved elsewhere.
I've attached a patch to reduce the STATUS file to what I think it should
be; please 'test' the patch (apply it to your own copy) and see whether
there's general agreement.

Since there's no indication in the STATUS or CHANGES files that there
have been any commits since the 10.0.2.1 release, I elided all the
'patches applied' paragraphs.  If any of those have actually been
applied since 10.0.2.1, they should be added back in.

Oh, and when there are patches available, a link to the submission
message should be included (ref. the RetrieveMessages patch).

What the STATUS file contains *is* up to the developers, but this
message is a mentor-guidance suggestion thing.

</hat>
- --
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBQe5cQprNPMCpn3XdAQGe2QQAynLV+mOOAyGclOWEFuLV/1xbsB09rnrU
Y8zQGXiQ3Mrg5+xC6pHhujO6NQ6CoivtGx0zN5u7Xatq0a0K1GIxbMYk5oz3opma
vTSMjqUwLCX7APzC8Pg1x4YGzVzZsKP7wYeDZo7GzPz3teVwqWzKwj6S8xnUzX8G
ixoEYv855JI=
=lNtt
-----END PGP SIGNATURE-----

Re: Versioning, contents of STATUS and CHANGES files

[Jeremy Boynes <jb...@apache.org>]

Daniel John Debrunner wrote:
> Rodent of Unusual Size wrote:
> 
> 
>>>Have there been no changes to the code since the release of 10.0.2.1?
>>>If there have been, they should be getting recorded in the trunk/CHANGES
>>>file, at the top, under a heading such as
>>>
>>>Changes in Derby 10.0.2.2-dev
>>>
>>>(or whatever version number is being used/embedded to identify
>>>the code as alpha/beta).  At the 10.0.2.2 release, that gets altered
>>>to 'Changes with 10.0.2.2' and a new 'Changes with 10.0.2.3-dev'
>>>heading is started above it.  Otherwise the CHANGES file won't change
>>>except at releases, which is a disservice to people observing or
>>>getting involved in the development mid-stream.
> 
> 
> Can the contents of the CHANGES files (for the trunk and each branch) be
> created automatically from the svn commit log. It's a little tedious and
> error prone to have to update something manually, when it could be
> automated.
> 

Rather than the commit log, I would suggest generating from the Jira 
entries associated with a release. You can also have a Jira digest 
mailed out periodically summarizing progress to date. This does rely on 
having Jira entries associated with work done but that is probably a 
good thing anyway.

The concern I have using the commit log is that larger changes may get 
spread over multiple commits (early, often) which the reader then has to 
stitch back together. Not really an issue for changes that are fairly 
atomic bug-fixes, but more of a challenge when planning a release with 
some really big features.

--
Jeremy

Re: Versioning, contents of STATUS and CHANGES files

[Daniel John Debrunner <dj...@debrunners.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rodent of Unusual Size wrote:

>
> Have there been no changes to the code since the release of 10.0.2.1?
> If there have been, they should be getting recorded in the trunk/CHANGES
> file, at the top, under a heading such as
>
> Changes in Derby 10.0.2.2-dev
>
> (or whatever version number is being used/embedded to identify
> the code as alpha/beta).  At the 10.0.2.2 release, that gets altered
> to 'Changes with 10.0.2.2' and a new 'Changes with 10.0.2.3-dev'
> heading is started above it.  Otherwise the CHANGES file won't change
> except at releases, which is a disservice to people observing or
> getting involved in the development mid-stream.

Can the contents of the CHANGES files (for the trunk and each branch) be
created automatically from the svn commit log. It's a little tedious and
error prone to have to update something manually, when it could be
automated.

Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFB7q76Iv0S4qsbfuQRAjPDAJ4pytp7C+UrSFh3ijwIEMujPF0tBACgyeqi
FPYGb7p42y8ueEeZl9PAJZM=
=toKe
-----END PGP SIGNATURE-----

Re: help for new developers

["Jean T. Anderson" <jt...@bristowhill.com>]

shahbaz chaudhary wrote:

> ...
> (by the way, is there a way to receive a single digest of messages a day?
> ...

I tried to describe that in the second paragraph on 
http://incubator.apache.org/derby/derby_mail.html, but that explanation 
I concocted doesn't look quite right, so I'll fix it.

I just sent an empty email to derby-dev-info@db.apache.org. From the 
response, it looks like all you need to do is send an empty email to 
derby-dev-digest-subscribe@db.apache.org 
<ma...@db.apache.org> to get the daily digest.

 -jean

help for new developers

[shahbaz chaudhary <c_...@hotmail.com>]

Someone recently requested design documents...something more developer 
oriented than what is under "Manuals' and something more indepth than the 
recent presentations and Apache and Colorado Software summits.
I would also like to make a suggestion.  As developers with greater exposure 
to derby/cloudescape source code develop new functions, perhaps they could 
also do a descriptive write-up of what they change, what they had to keep in 
mind, etc.
I, myself, would eventually like to experiment with some CUBE/ROLLUP 
functionality...but traversing the code is not trivial.

Perhaps example implementations of relitively simple things like:
1. HAVING clause
2. distinct aggregates
3. some storage/access/io level examples such as the ability to read a text 
file with arbitray delimiters

Look foward to it!

(by the way, is there a way to receive a single digest of messages a day?  
Otherwise this email list will further fill up my email account.)

Falcon