You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2014/07/23 01:07:54 UTC
release vs. SNAPSHOT sites.
Hi All:
Snapshots site are useless to users and somewhat useful to developers.
It is nice to be able to republish a site at will to fix documentation bugs
_without_ releasing a new version.
But, this is usually done by dragging along a SNAPSHOT version of
everything.
What to do?
We need to publish the current version of a component and keep it there, as
is. What about doc only changes? What if those fixes are Javadoc fixes?
Does not seem doable.
We could have, on the side a SNAPSHOT site.
That means two sites: RELEASE and SNAPSHOT.
Thoughts?
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: release vs. SNAPSHOT sites.
Posted by Mark Thomas <ma...@apache.org>.
On 27/07/2014 15:15, Phil Steitz wrote:
> On Sun, Jul 27, 2014 at 4:24 AM, sebb <se...@gmail.com> wrote:
>
>> On 26 July 2014 19:09, Phil Steitz <ph...@gmail.com> wrote:
>>>
>>>
>>>> On Jul 26, 2014, at 6:16 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>>>
>>>> OK, so do we want:
>>>>
>>>> - Always have the release site be the "main" site.
>>>> - Optionally have a separate SNAPSHOT site.
>>>>
>>>> Do we put this magic in commons-parent?
>>>
>>> I prefer the opposite - site is current dev.
>>
>> That is of little use to end users.
>>
>
> I think it is important that the site shows what is going on in the project
> - that is *current dev*. As long as end users can get the latest release
> easily and the latest javadoc is linked, their needs are met and more
> importantly if we keep the site up to date they can see *where the project
> is going*. I guess I see the site as more a *project site* rather than
> an archive. Our "end users" are developers and we want to encourage them
> to get involved via the web sites.
I disagree. I suspect most users go to the web site looking for
information on how to use the (hopefully current) version of the
software they are using. Having the docs for the next version causes
confusion when the docs refer to a feature that is only on trunk.
> That means putting documentation on the
> latest, greatest, not-yet-released stuff up for them to look at.
There is a place for that sort of information as well.
Taking Tomcat as an example, the web site has the docs for the latest
releases but we also have links to the CI system that builds the docs as
part of the CI builds so we can point folks to the bleeding edge docs if
necessary.
> I would
> not be opposed to publishing a commons archive site somewhere if someone
> wants to scratch that itch; but the component sites should not try to be
> that, IMO.
I don't think we need to provide the docs for every release but I do
think docs for the latest release are more useful than docs for the
current trunk.
Of course, the more frequently we release, the smaller the delta anyway.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: release vs. SNAPSHOT sites.
Posted by Phil Steitz <ph...@gmail.com>.
On Sun, Jul 27, 2014 at 4:24 AM, sebb <se...@gmail.com> wrote:
> On 26 July 2014 19:09, Phil Steitz <ph...@gmail.com> wrote:
> >
> >
> >> On Jul 26, 2014, at 6:16 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>
> >> OK, so do we want:
> >>
> >> - Always have the release site be the "main" site.
> >> - Optionally have a separate SNAPSHOT site.
> >>
> >> Do we put this magic in commons-parent?
> >
> > I prefer the opposite - site is current dev.
>
> That is of little use to end users.
>
I think it is important that the site shows what is going on in the project
- that is *current dev*. As long as end users can get the latest release
easily and the latest javadoc is linked, their needs are met and more
importantly if we keep the site up to date they can see *where the project
is going*. I guess I see the site as more a *project site* rather than
an archive. Our "end users" are developers and we want to encourage them
to get involved via the web sites. That means putting documentation on the
latest, greatest, not-yet-released stuff up for them to look at. I would
not be opposed to publishing a commons archive site somewhere if someone
wants to scratch that itch; but the component sites should not try to be
that, IMO.
>
> > Download pages always reflect latest release (in some cases multiple).
>
> Agreed.
>
> > Last released javadoc must be linked.
>
> Agreed.
>
> > Older (released) javadoc is good to have, as is current dev javadoc.
>
> Agreed.
>
> > Old (released) user guide, etc is optional.
>
> Current (released) user guide etc is mandatory.
>
Well, we disagree here then. We have never had the "requirement" before
and I am -1 to adding it now.
Phil
>
> > Phil
> >>
> >> Gary
> >>
> >>
> >>> On Sat, Jul 26, 2014 at 7:07 AM, sebb <se...@gmail.com> wrote:
> >>>
> >>>> On 25 July 2014 18:03, Stefan Bodewig <bo...@apache.org> wrote:
> >>>>> On 2014-07-25, Gary Gregory wrote:
> >>>>>
> >>>>> It's that or we agree never to publish a SNAPSHOT site.
> >>>
> >>> I don't see that as a strict dichotomy.
> >>>
> >>>> For the record, I do value SNAPSHOT sites so we can also show what we
> >>>> are working on.
> >>>
> >>> That does not necessarily need a whole snapshot site.
> >>> A news page would be sufficient in many cases.
> >>>
> >>>> I'm not convinced we need to enforce the same policy
> >>>> for all components. OTOH I don't feel strong enough about it to
> really
> >>>> block a decision that discourages/prohibits SHAPSHOT sites.
> >>>
> >>> Agreed, so long as the SNAPSHOT site does not replace the site for the
> >>> release.
> >>> It's vital that users can easily get access to the docs for the
> >>> current release(s).
> >>>
> >>>> Stefan
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> Java Persistence with Hibernate, Second Edition
> >> <http://www.manning.com/bauer3/>
> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: release vs. SNAPSHOT sites.
Posted by sebb <se...@gmail.com>.
On 26 July 2014 19:09, Phil Steitz <ph...@gmail.com> wrote:
>
>
>> On Jul 26, 2014, at 6:16 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> OK, so do we want:
>>
>> - Always have the release site be the "main" site.
>> - Optionally have a separate SNAPSHOT site.
>>
>> Do we put this magic in commons-parent?
>
> I prefer the opposite - site is current dev.
That is of little use to end users.
> Download pages always reflect latest release (in some cases multiple).
Agreed.
> Last released javadoc must be linked.
Agreed.
> Older (released) javadoc is good to have, as is current dev javadoc.
Agreed.
> Old (released) user guide, etc is optional.
Current (released) user guide etc is mandatory.
> Phil
>>
>> Gary
>>
>>
>>> On Sat, Jul 26, 2014 at 7:07 AM, sebb <se...@gmail.com> wrote:
>>>
>>>> On 25 July 2014 18:03, Stefan Bodewig <bo...@apache.org> wrote:
>>>>> On 2014-07-25, Gary Gregory wrote:
>>>>>
>>>>> It's that or we agree never to publish a SNAPSHOT site.
>>>
>>> I don't see that as a strict dichotomy.
>>>
>>>> For the record, I do value SNAPSHOT sites so we can also show what we
>>>> are working on.
>>>
>>> That does not necessarily need a whole snapshot site.
>>> A news page would be sufficient in many cases.
>>>
>>>> I'm not convinced we need to enforce the same policy
>>>> for all components. OTOH I don't feel strong enough about it to really
>>>> block a decision that discourages/prohibits SHAPSHOT sites.
>>>
>>> Agreed, so long as the SNAPSHOT site does not replace the site for the
>>> release.
>>> It's vital that users can easily get access to the docs for the
>>> current release(s).
>>>
>>>> Stefan
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: release vs. SNAPSHOT sites.
Posted by Phil Steitz <ph...@gmail.com>.
> On Jul 26, 2014, at 6:16 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> OK, so do we want:
>
> - Always have the release site be the "main" site.
> - Optionally have a separate SNAPSHOT site.
>
> Do we put this magic in commons-parent?
I prefer the opposite - site is current dev. Download pages always reflect latest release (in some cases multiple). Last released javadoc must be linked. Older (released) javadoc is good to have, as is current dev javadoc. Old (released) user guide, etc is optional.
Phil
>
> Gary
>
>
>> On Sat, Jul 26, 2014 at 7:07 AM, sebb <se...@gmail.com> wrote:
>>
>>> On 25 July 2014 18:03, Stefan Bodewig <bo...@apache.org> wrote:
>>>> On 2014-07-25, Gary Gregory wrote:
>>>>
>>>> It's that or we agree never to publish a SNAPSHOT site.
>>
>> I don't see that as a strict dichotomy.
>>
>>> For the record, I do value SNAPSHOT sites so we can also show what we
>>> are working on.
>>
>> That does not necessarily need a whole snapshot site.
>> A news page would be sufficient in many cases.
>>
>>> I'm not convinced we need to enforce the same policy
>>> for all components. OTOH I don't feel strong enough about it to really
>>> block a decision that discourages/prohibits SHAPSHOT sites.
>>
>> Agreed, so long as the SNAPSHOT site does not replace the site for the
>> release.
>> It's vital that users can easily get access to the docs for the
>> current release(s).
>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: release vs. SNAPSHOT sites.
Posted by Gary Gregory <ga...@gmail.com>.
OK, so do we want:
- Always have the release site be the "main" site.
- Optionally have a separate SNAPSHOT site.
Do we put this magic in commons-parent?
Gary
On Sat, Jul 26, 2014 at 7:07 AM, sebb <se...@gmail.com> wrote:
> On 25 July 2014 18:03, Stefan Bodewig <bo...@apache.org> wrote:
> > On 2014-07-25, Gary Gregory wrote:
> >
> >> It's that or we agree never to publish a SNAPSHOT site.
>
> I don't see that as a strict dichotomy.
>
> > For the record, I do value SNAPSHOT sites so we can also show what we
> > are working on.
>
> That does not necessarily need a whole snapshot site.
> A news page would be sufficient in many cases.
>
> > I'm not convinced we need to enforce the same policy
> > for all components. OTOH I don't feel strong enough about it to really
> > block a decision that discourages/prohibits SHAPSHOT sites.
>
> Agreed, so long as the SNAPSHOT site does not replace the site for the
> release.
> It's vital that users can easily get access to the docs for the
> current release(s).
>
> > Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: release vs. SNAPSHOT sites.
Posted by sebb <se...@gmail.com>.
On 25 July 2014 18:03, Stefan Bodewig <bo...@apache.org> wrote:
> On 2014-07-25, Gary Gregory wrote:
>
>> It's that or we agree never to publish a SNAPSHOT site.
I don't see that as a strict dichotomy.
> For the record, I do value SNAPSHOT sites so we can also show what we
> are working on.
That does not necessarily need a whole snapshot site.
A news page would be sufficient in many cases.
> I'm not convinced we need to enforce the same policy
> for all components. OTOH I don't feel strong enough about it to really
> block a decision that discourages/prohibits SHAPSHOT sites.
Agreed, so long as the SNAPSHOT site does not replace the site for the release.
It's vital that users can easily get access to the docs for the
current release(s).
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: release vs. SNAPSHOT sites.
Posted by Stefan Bodewig <bo...@apache.org>.
On 2014-07-25, Gary Gregory wrote:
> It's that or we agree never to publish a SNAPSHOT site.
For the record, I do value SNAPSHOT sites so we can also show what we
are working on. I'm not convinced we need to enforce the same policy
for all components. OTOH I don't feel strong enough about it to really
block a decision that discourages/prohibits SHAPSHOT sites.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: release vs. SNAPSHOT sites.
Posted by Gary Gregory <ga...@gmail.com>.
But the point is to be able to update the site with documentation fixes
while keeping the rest of the site about the released software.
The only way to do that is with documentation-only branch it sounds like,
and it does not matter what SCM you use for that.
It's that or we agree never to publish a SNAPSHOT site.
Gary
On Fri, Jul 25, 2014 at 5:35 AM, Benedikt Ritter <br...@apache.org> wrote:
> BTW.: I don't see any value in the SNAPSHOT site. Users will always want to
> look at the site of the release, since that is what they are using.
>
>
> 2014-07-25 11:34 GMT+02:00 Benedikt Ritter <br...@apache.org>:
>
> > You're probably refering to the Dependency Information report, I've
> posted
> > on the other thread. I think it would be sufficient to configure it to
> use
> > the latest release (we already have this information in the properties
> used
> > by the build plugin).
> >
> > Creating a documentation branch feels like a lot of overhead to me. I'm
> > curious whether git would make this any easier, since working with
> branches
> > is said to be easier in git.
> >
> > Benedikt
> >
> >
> > 2014-07-23 1:07 GMT+02:00 Gary Gregory <ga...@gmail.com>:
> >
> > Hi All:
> >>
> >> Snapshots site are useless to users and somewhat useful to developers.
> >>
> >> It is nice to be able to republish a site at will to fix documentation
> >> bugs
> >> _without_ releasing a new version.
> >>
> >> But, this is usually done by dragging along a SNAPSHOT version of
> >> everything.
> >>
> >> What to do?
> >>
> >> We need to publish the current version of a component and keep it there,
> >> as
> >> is. What about doc only changes? What if those fixes are Javadoc fixes?
> >> Does not seem doable.
> >>
> >> We could have, on the side a SNAPSHOT site.
> >>
> >> That means two sites: RELEASE and SNAPSHOT.
> >>
> >> Thoughts?
> >>
> >> Gary
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> Java Persistence with Hibernate, Second Edition
> >> <http://www.manning.com/bauer3/>
> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >>
> >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: release vs. SNAPSHOT sites.
Posted by Benedikt Ritter <br...@apache.org>.
BTW.: I don't see any value in the SNAPSHOT site. Users will always want to
look at the site of the release, since that is what they are using.
2014-07-25 11:34 GMT+02:00 Benedikt Ritter <br...@apache.org>:
> You're probably refering to the Dependency Information report, I've posted
> on the other thread. I think it would be sufficient to configure it to use
> the latest release (we already have this information in the properties used
> by the build plugin).
>
> Creating a documentation branch feels like a lot of overhead to me. I'm
> curious whether git would make this any easier, since working with branches
> is said to be easier in git.
>
> Benedikt
>
>
> 2014-07-23 1:07 GMT+02:00 Gary Gregory <ga...@gmail.com>:
>
> Hi All:
>>
>> Snapshots site are useless to users and somewhat useful to developers.
>>
>> It is nice to be able to republish a site at will to fix documentation
>> bugs
>> _without_ releasing a new version.
>>
>> But, this is usually done by dragging along a SNAPSHOT version of
>> everything.
>>
>> What to do?
>>
>> We need to publish the current version of a component and keep it there,
>> as
>> is. What about doc only changes? What if those fixes are Javadoc fixes?
>> Does not seem doable.
>>
>> We could have, on the side a SNAPSHOT site.
>>
>> That means two sites: RELEASE and SNAPSHOT.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: release vs. SNAPSHOT sites.
Posted by Benedikt Ritter <br...@apache.org>.
You're probably refering to the Dependency Information report, I've posted
on the other thread. I think it would be sufficient to configure it to use
the latest release (we already have this information in the properties used
by the build plugin).
Creating a documentation branch feels like a lot of overhead to me. I'm
curious whether git would make this any easier, since working with branches
is said to be easier in git.
Benedikt
2014-07-23 1:07 GMT+02:00 Gary Gregory <ga...@gmail.com>:
> Hi All:
>
> Snapshots site are useless to users and somewhat useful to developers.
>
> It is nice to be able to republish a site at will to fix documentation bugs
> _without_ releasing a new version.
>
> But, this is usually done by dragging along a SNAPSHOT version of
> everything.
>
> What to do?
>
> We need to publish the current version of a component and keep it there, as
> is. What about doc only changes? What if those fixes are Javadoc fixes?
> Does not seem doable.
>
> We could have, on the side a SNAPSHOT site.
>
> That means two sites: RELEASE and SNAPSHOT.
>
> Thoughts?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: release vs. SNAPSHOT sites.
Posted by sebb <se...@gmail.com>.
On 23 July 2014 00:07, Gary Gregory <ga...@gmail.com> wrote:
> Hi All:
>
> Snapshots site are useless to users and somewhat useful to developers.
>
> It is nice to be able to republish a site at will to fix documentation bugs
> _without_ releasing a new version.
>
> But, this is usually done by dragging along a SNAPSHOT version of
> everything.
>
> What to do?
>
> We need to publish the current version of a component and keep it there, as
> is. What about doc only changes? What if those fixes are Javadoc fixes?
> Does not seem doable.
>
> We could have, on the side a SNAPSHOT site.
>
> That means two sites: RELEASE and SNAPSHOT.
In JMeter, we create a branch for the documentation from the release.
Any documentation fixes can then be applied to the branch (and trunk
if relevant) and the branch used to recreate the site.
At present we do not include Javadoc in the branch, but it should be
possible to do so.
Obviously there must not be any code changes applied to the branch
when using this process.
> Thoughts?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org