You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Will Glass-Husain <wg...@forio.com> on 2007/01/29 01:28:01 UTC

readme docs

Henning,

I'm holding off with my vote for the moment-- I've some minor concerns
on the docs.  Am I allowed to make the changes or since we are in the
middle of a vote is it too late?

I'm worried about making sure existing users of 1.4 have a seamless
upgrade experience.  I drafted some text in the Wiki, but I think it's
mostly superseded now.  But we should add to the README.txt file
something like:

This release is a drop-in replacement for earlier versions of
Velocity. No changes to your application should be required other than
changes to the dependent jar files.  Specific changes to the jar files
include:
* JDOM has been upgraded to 1.0
* Commons Collection has been upgraded to 3.1
* Commons Lang 2.1 has been added

In addition,
* Ant 1.6  or greater is required for building.
* Java CC 3.2 or greater is now required for compiling parser files.
* HSQLDB 1.7.1 is required for running unit tests.

I worry about this, because when I tried last Fall to upgrade an app
of mine to Velocity 1.5-beta, the commons collection upgrade was
really a hassle.  (due to a conflicting conflict with Torque 3.0 which
requires an earlier version).  We need to highlight this change.

A minor issue:  xdocs/docs/jar-dependencies.xml is inconsistent with
xdocs/docs/build.xml.  Specifically the list of dependencies is
missing antlr and junit.

best,
WILL

On 1/28/07, Henning Schmiedehausen <he...@apache.org> wrote:
> On Sun, 2007-01-28 at 23:25 +0100, Henning Schmiedehausen wrote:
> > [X] +1 Yes.
> > [ ]  0 I still don't care.
> > [ ] -1 No, because ________________________________.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: private-unsubscribe@velocity.apache.org
> For additional commands, e-mail: private-help@velocity.apache.org
>
>


-- 
Forio Business Simulations

Will Glass-Husain
wglass@forio.com
www.forio.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org


Re: readme docs

Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Claude Brisson <cl...@renegat.net> writes:

>The only irreversible stage is the release itself, not the vote.

I fully agree. However, as Geir stated correctly, the release happens
before the vote. The vote only decides whether we make a rolled
tar-ball [1] "public" and an "official Apache Velocity release" or
not.

Re-rolling the tar-ball means repeating the vote. That is why we vote
twice.

	Best regards
		Henning

[1] or zip-ball. YMMV.

-- 
Henning P. Schmiedehausen  -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany   -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy

          "Save the cheerleader. Save the world."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org


Re: readme docs

Posted by Claude Brisson <cl...@renegat.net>.
IMHO, taking into account a constructive remark about a change in the
readme file should not interrupt the vote nor the release process. This
is voluntariate time we are spoiling otherwise.

The vote is in itself a good moment to react about the state of the
upcoming release - it'd be rather strange to start it again after any
change, especially in document, and especially when the remark is
obviously constructive.

The only irreversible stage is the release itself, not the vote.

  Claude

Le lundi 29 janvier 2007 à 14:07 -0800, Will Glass-Husain a écrit :
> Hi Henning,
> 
> Ok, that makes sense.  We didn't catch this till the vote started, so
> it's too late unless we want to delay till March.
> 
> All I'm really worried about is the existing users missing the JDOM
> and commons-collection upgrade.  I'm expecting that most users will
> just download the new jar, drop it into their application, and see if
> it works.  (so the downloading in the ant build isn't relevant)
>  Let's mention the JDOM and commons-collection upgrade explicitly in
> the announcement and on the web site and I'll feel better.
> 
> I'm going to test the JAR file tonight (just a double-check; not
> expecting any problems) then will vote.
> 
> cheers,
> WILL
> 
> 
> On 1/29/07, Henning P. Schmiedehausen <hp...@intermeta.de> wrote:
> > "Will Glass-Husain" <wg...@forio.com> writes:
> >
> > >Henning,
> >
> > Hi,
> >
> > >I'm holding off with my vote for the moment-- I've some minor concerns
> > >on the docs.  Am I allowed to make the changes or since we are in the
> > >middle of a vote is it too late?
> >
> > Actually, as we decided to vote on the release binaries, this would
> > mean that we have to cancel the vote and re-release.
> >
> > >I'm worried about making sure existing users of 1.4 have a seamless
> > >upgrade experience.  I drafted some text in the Wiki, but I think it's
> > >mostly superseded now.  But we should add to the README.txt file
> > >something like:
> >
> > I'm completely +1 adding this to the HEAD README. But for the actual
> > relase binaries, this would mean re-rolling (probably as 1.5.1 with a
> > message that we cancelled 1.5) and re-voting.
> >
> > If we don't have these changes in the docs (which basically is a
> > non-requirement as the dependencies get downloaded from the Internet
> > ), what does ist cost us? And frankly: Who will really rebuild the
> > Parser/Lexer without ever consulting the mailing list?
> >
> > >This release is a drop-in replacement for earlier versions of
> > >Velocity. No changes to your application should be required other than
> > >changes to the dependent jar files.  Specific changes to the jar files
> > >include:
> > >* JDOM has been upgraded to 1.0
> > >* Commons Collection has been upgraded to 3.1
> > >* Commons Lang 2.1 has been added
> >
> > >In addition,
> > >* Ant 1.6  or greater is required for building.
> > >* Java CC 3.2 or greater is now required for compiling parser files.
> > >* HSQLDB 1.7.1 is required for running unit tests.
> >
> > >I worry about this, because when I tried last Fall to upgrade an app
> > >of mine to Velocity 1.5-beta, the commons collection upgrade was
> > >really a hassle.  (due to a conflicting conflict with Torque 3.0 which
> > >requires an earlier version).  We need to highlight this change.
> >
> > >A minor issue:  xdocs/docs/jar-dependencies.xml is inconsistent with
> > >xdocs/docs/build.xml.  Specifically the list of dependencies is
> > >missing antlr and junit.
> >
> > Yes. The docs are not perfect. I do admit that at some point I was fed
> > up with fixing docs. I want to go back to coding. We all do not really
> > shine at doing documentation and this is real opportunity for any
> > contributor to step up and help (help wanted!).
> >
> > The docs have been in a worse state for a very long time. No one ever
> > fixed them, no one (neither on user nor on dev) really complained
> > about it (we did get a bug report about missing ', though. ;-) ).
> >
> > If the upgrade *is* really a problem and we see major concerns from
> > the user list, we can do a 1.5.1 release on short notice. No problem
> > here.
> >
> > After we merge the changes from the release branch back to the HEAD,
> > we can build and publish updated docs to the devel web site. Also: no
> > problem. When the release site and the devel site differ: Well, that
> > is why we have two sites now.
> >
> > But what we do have ATM is momentum for the release. I don't want to
> > squelch that. We have people anticipating the release. Waiting for it
> > for quite some time. It is still a tiny bit rough around the edges but
> > it is light years ahead of what was available for a very long time.
> >
> > Did I rush it in the end? Yes, I did, I am guilty about it and I fully
> > accept the blame.
> >
> > The reason is the unfortunate collision of this *expletive deleted*
> > build tool called "maven 2", the fact that our zone ticket is now open
> > and unprocessed for more than three weeks and my upcoming holidays.
> >
> > So I know that currently, I'm probably the only person that is able to
> > build the site (which does suck, I know). But if we delay the release
> > again, then one of you will have to release it in February at the
> > price that the site will almost surely not be up-to-date. Which sucks
> > IMHO more than having two dependencies wrong in a README that most
> > people don't look at. :-)
> >
> > So, unless you consider that a *real* show stopper (and I promise to
> > deal with all the users that complain about having to update their
> > commons-collections once I get back from Down Under), I would like to
> > go ahead.
> >
> >         Best regards
> >                 Henning
> >
> > --
> > Henning P. Schmiedehausen  -- hps@intermeta.de | J2EE, Linux,
> > 91054 Buckenhof, Germany   -- +49 9131 506540 | Apache person
> > Open Source Consulting, Development, Design | Velocity - Turbine guy
> >
> >           "Save the cheerleader. Save the world."
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: dev-help@velocity.apache.org
> >
> >
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org


Re: readme docs

Posted by Will Glass-Husain <wg...@gmail.com>.
Hi Henning,

Ok, that makes sense.  We didn't catch this till the vote started, so
it's too late unless we want to delay till March.

All I'm really worried about is the existing users missing the JDOM
and commons-collection upgrade.  I'm expecting that most users will
just download the new jar, drop it into their application, and see if
it works.  (so the downloading in the ant build isn't relevant)
 Let's mention the JDOM and commons-collection upgrade explicitly in
the announcement and on the web site and I'll feel better.

I'm going to test the JAR file tonight (just a double-check; not
expecting any problems) then will vote.

cheers,
WILL


On 1/29/07, Henning P. Schmiedehausen <hp...@intermeta.de> wrote:
> "Will Glass-Husain" <wg...@forio.com> writes:
>
> >Henning,
>
> Hi,
>
> >I'm holding off with my vote for the moment-- I've some minor concerns
> >on the docs.  Am I allowed to make the changes or since we are in the
> >middle of a vote is it too late?
>
> Actually, as we decided to vote on the release binaries, this would
> mean that we have to cancel the vote and re-release.
>
> >I'm worried about making sure existing users of 1.4 have a seamless
> >upgrade experience.  I drafted some text in the Wiki, but I think it's
> >mostly superseded now.  But we should add to the README.txt file
> >something like:
>
> I'm completely +1 adding this to the HEAD README. But for the actual
> relase binaries, this would mean re-rolling (probably as 1.5.1 with a
> message that we cancelled 1.5) and re-voting.
>
> If we don't have these changes in the docs (which basically is a
> non-requirement as the dependencies get downloaded from the Internet
> ), what does ist cost us? And frankly: Who will really rebuild the
> Parser/Lexer without ever consulting the mailing list?
>
> >This release is a drop-in replacement for earlier versions of
> >Velocity. No changes to your application should be required other than
> >changes to the dependent jar files.  Specific changes to the jar files
> >include:
> >* JDOM has been upgraded to 1.0
> >* Commons Collection has been upgraded to 3.1
> >* Commons Lang 2.1 has been added
>
> >In addition,
> >* Ant 1.6  or greater is required for building.
> >* Java CC 3.2 or greater is now required for compiling parser files.
> >* HSQLDB 1.7.1 is required for running unit tests.
>
> >I worry about this, because when I tried last Fall to upgrade an app
> >of mine to Velocity 1.5-beta, the commons collection upgrade was
> >really a hassle.  (due to a conflicting conflict with Torque 3.0 which
> >requires an earlier version).  We need to highlight this change.
>
> >A minor issue:  xdocs/docs/jar-dependencies.xml is inconsistent with
> >xdocs/docs/build.xml.  Specifically the list of dependencies is
> >missing antlr and junit.
>
> Yes. The docs are not perfect. I do admit that at some point I was fed
> up with fixing docs. I want to go back to coding. We all do not really
> shine at doing documentation and this is real opportunity for any
> contributor to step up and help (help wanted!).
>
> The docs have been in a worse state for a very long time. No one ever
> fixed them, no one (neither on user nor on dev) really complained
> about it (we did get a bug report about missing ', though. ;-) ).
>
> If the upgrade *is* really a problem and we see major concerns from
> the user list, we can do a 1.5.1 release on short notice. No problem
> here.
>
> After we merge the changes from the release branch back to the HEAD,
> we can build and publish updated docs to the devel web site. Also: no
> problem. When the release site and the devel site differ: Well, that
> is why we have two sites now.
>
> But what we do have ATM is momentum for the release. I don't want to
> squelch that. We have people anticipating the release. Waiting for it
> for quite some time. It is still a tiny bit rough around the edges but
> it is light years ahead of what was available for a very long time.
>
> Did I rush it in the end? Yes, I did, I am guilty about it and I fully
> accept the blame.
>
> The reason is the unfortunate collision of this *expletive deleted*
> build tool called "maven 2", the fact that our zone ticket is now open
> and unprocessed for more than three weeks and my upcoming holidays.
>
> So I know that currently, I'm probably the only person that is able to
> build the site (which does suck, I know). But if we delay the release
> again, then one of you will have to release it in February at the
> price that the site will almost surely not be up-to-date. Which sucks
> IMHO more than having two dependencies wrong in a README that most
> people don't look at. :-)
>
> So, unless you consider that a *real* show stopper (and I promise to
> deal with all the users that complain about having to update their
> commons-collections once I get back from Down Under), I would like to
> go ahead.
>
>         Best regards
>                 Henning
>
> --
> Henning P. Schmiedehausen  -- hps@intermeta.de | J2EE, Linux,
> 91054 Buckenhof, Germany   -- +49 9131 506540 | Apache person
> Open Source Consulting, Development, Design | Velocity - Turbine guy
>
>           "Save the cheerleader. Save the world."
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>


-- 
Forio Business Simulations

Will Glass-Husain
wglass@forio.com
www.forio.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org


Re: readme docs

Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Will Glass-Husain" <wg...@forio.com> writes:

>Henning,

Hi,

>I'm holding off with my vote for the moment-- I've some minor concerns
>on the docs.  Am I allowed to make the changes or since we are in the
>middle of a vote is it too late?

Actually, as we decided to vote on the release binaries, this would
mean that we have to cancel the vote and re-release.

>I'm worried about making sure existing users of 1.4 have a seamless
>upgrade experience.  I drafted some text in the Wiki, but I think it's
>mostly superseded now.  But we should add to the README.txt file
>something like:

I'm completely +1 adding this to the HEAD README. But for the actual
relase binaries, this would mean re-rolling (probably as 1.5.1 with a
message that we cancelled 1.5) and re-voting.

If we don't have these changes in the docs (which basically is a
non-requirement as the dependencies get downloaded from the Internet
), what does ist cost us? And frankly: Who will really rebuild the
Parser/Lexer without ever consulting the mailing list?

>This release is a drop-in replacement for earlier versions of
>Velocity. No changes to your application should be required other than
>changes to the dependent jar files.  Specific changes to the jar files
>include:
>* JDOM has been upgraded to 1.0
>* Commons Collection has been upgraded to 3.1
>* Commons Lang 2.1 has been added

>In addition,
>* Ant 1.6  or greater is required for building.
>* Java CC 3.2 or greater is now required for compiling parser files.
>* HSQLDB 1.7.1 is required for running unit tests.

>I worry about this, because when I tried last Fall to upgrade an app
>of mine to Velocity 1.5-beta, the commons collection upgrade was
>really a hassle.  (due to a conflicting conflict with Torque 3.0 which
>requires an earlier version).  We need to highlight this change.

>A minor issue:  xdocs/docs/jar-dependencies.xml is inconsistent with
>xdocs/docs/build.xml.  Specifically the list of dependencies is
>missing antlr and junit.

Yes. The docs are not perfect. I do admit that at some point I was fed
up with fixing docs. I want to go back to coding. We all do not really
shine at doing documentation and this is real opportunity for any
contributor to step up and help (help wanted!).

The docs have been in a worse state for a very long time. No one ever
fixed them, no one (neither on user nor on dev) really complained
about it (we did get a bug report about missing ', though. ;-) ).

If the upgrade *is* really a problem and we see major concerns from
the user list, we can do a 1.5.1 release on short notice. No problem
here.

After we merge the changes from the release branch back to the HEAD,
we can build and publish updated docs to the devel web site. Also: no
problem. When the release site and the devel site differ: Well, that
is why we have two sites now.

But what we do have ATM is momentum for the release. I don't want to
squelch that. We have people anticipating the release. Waiting for it
for quite some time. It is still a tiny bit rough around the edges but
it is light years ahead of what was available for a very long time.

Did I rush it in the end? Yes, I did, I am guilty about it and I fully
accept the blame.

The reason is the unfortunate collision of this *expletive deleted*
build tool called "maven 2", the fact that our zone ticket is now open
and unprocessed for more than three weeks and my upcoming holidays.

So I know that currently, I'm probably the only person that is able to
build the site (which does suck, I know). But if we delay the release
again, then one of you will have to release it in February at the
price that the site will almost surely not be up-to-date. Which sucks
IMHO more than having two dependencies wrong in a README that most
people don't look at. :-)

So, unless you consider that a *real* show stopper (and I promise to
deal with all the users that complain about having to update their
commons-collections once I get back from Down Under), I would like to
go ahead.

	Best regards
		Henning

-- 
Henning P. Schmiedehausen  -- hps@intermeta.de | J2EE, Linux,
91054 Buckenhof, Germany   -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine guy

          "Save the cheerleader. Save the world."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org