hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [VOTE][LAZY] Release HC stylecheck 1 based on RC1
Date Wed, 12 Jun 2013 22:07:26 GMT
On Wed, 2013-06-12 at 16:00 -0400, Gary Gregory wrote:
> On Wed, Jun 12, 2013 at 3:46 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
> 
> > On Wed, 2013-06-12 at 11:49 -0400, Gary Gregory wrote:
> > > On Wed, Jun 12, 2013 at 11:30 AM, Oleg Kalnichevski <olegk@apache.org
> > >wrote:
> > >
> > > > On Wed, 2013-06-12 at 11:21 -0400, Gary Gregory wrote:
> > > > > On Wed, Jun 12, 2013 at 11:15 AM, Oleg Kalnichevski <
> > olegk@apache.org
> > > > >wrote:
> > > > >
> > > > > > On Wed, 2013-06-12 at 11:10 -0400, Gary Gregory wrote:
> > > > > > > Can I step back a second and ask why we are not sharing
a
> > > > checkstyle.xml
> > > > > > > file, for example, the way we do it in Log4j 2, which is
also a
> > > > > > > multi-module project?
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > >
> > > > > > That is the whole point of publishing module: to make it re-usable
> > as a
> > > > > > binary artifact by all HC projects.
> > > > > >
> > > > >
> > > > > I understand the point of it, but it sure seems more complicated
that
> > > > just
> > > > > having a file sitting in the root directory.
> > > > >
> > > >
> > > > In the root directory of what exactly? We now have 4 (or maybe even
> > > > more) instances of hc-stylecheck.xml sitting around in various
> > > > directories.
> > > >
> > >
> > > Ah, I just looked at the directory layout of log4j2 vs. httpcomponents
> > and
> > > I see that both projects have a different approach to laying out modules.
> > >
> > > Log4j2 puts the 'project file' at the root and the submodules in
> > > subdirectories.
> > >
> > > Gary
> > >
> >
> > Gary,
> >
> > Obviously this approach works well for a group of modules that share the
> > same release cycle. In HC land we have three components with different
> > release cycles which makes our situation considerably more complex.
> >
> 
> Check. FWIW, I've always found the current release model unclear. I do not
> feed I can guarantee that core 4.2.x works with client 4.2.y or other
> combinations. The only thing I can be guaranteed is that the stack works as
> defined by the deps in the POMs.
> 
> For me at least, I'd be happy to link to a httpcomponents-all 4.3, get
> all-in-one jar and be done with it,
> 
> But hey, that's just me :)
> 
> Gary
> 

HC stable branches are not meant to have any public visible changes are
meant for bug fixes only. Likewise stable releases should never depend
on releases from a development branch.  

Everything in this life has pros and cons. Big ├╝ber all-in-one jars make
some things easier and others more difficult like management of
transitive dependencies. Same goes for one release cycle for distinct
group of components. One release cycle basically means that while core
components undergo a lot of changes, client components cannot be
released with a lower, more stable version, and vice versa. All comes
with a price.

Oleg



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


Mime
View raw message