[DISCUSS] versioning components

[Sean Busbey <bu...@apache.org>]

Hi folks!

We currently have 4 major components in Yetus:

* test-patch (the precommit QA checker)
* audience-annotations (java annotations for API definitions, and
related tooling)
* release-doc-maker (jira + git history linting and pretty-printed
release notes based on the result)
* shelldocs (API documentation generation out of bash)

I've been presuming we'll version these independently, if only because
I expect them to have different rates of change. One down side of this
presumption is that we'd need to have component-specific versions in
jira.

What do other folks think?

-- 
Sean

Re: [DISCUSS] versioning components

[Chris Nauroth <cn...@hortonworks.com>]

+1 for a single unifying version number right now.  It's something worth
reconsidering as the project evolves though.

--Chris Nauroth




On 9/23/15, 11:06 AM, "Mark Grover" <ma...@apache.org> wrote:

>Yeah, my vote is to stick to one release version for now as well. Easier
>to
>handle logistically and for our users to be able to say I am using YETUS
>X.Y.Z. As we mature, perhaps we can reconsider this decision but I
>personally have little motivation to vote for anything but 1 version
>number
>for now.
>
>On Wed, Sep 23, 2015 at 8:43 AM, Nick Dimiduk <nd...@apache.org> wrote:
>
>> I think we should keep our lives simple by shipping one release
>>artifact to
>> begin with. I second the concern of burdening ourselves with 4x the
>>VOTEs
>> for every release. Most projects start with a lot of change in the
>> beginning anyway, so it's likely that most of the components will be
>> updated with each release. Once we've gotten into the swing of things,
>>we
>> can consider breaking the bundle apart.
>>
>> As another example of a project that stitches together multiple
>>components
>> in a single build process, have a look at HTrace.
>>
>> On Wed, Sep 23, 2015 at 8:11 AM, Jarek Jarcec Cecho <ja...@apache.org>
>> wrote:
>>
>> > >> * if we release often enough, it won't matter that much if one part
>> > hasn't changed
>> > >
>> > > I had been thinking of this the opposite way; that if we release
>>often
>> > > we'll end up with many versions that are empty for some component
>>(in
>> > > particular audience-annotations).
>> > >
>> > > But I can't actually think of a problem with having "no changes in
>> > > this release" in the release note section on one or more components.
>> >
>> > I would like add few notes to this particular topic - I feel that it¹s
>> > always focusing for end user when there is a release of component that
>> > doesn¹t have any changes. From my perspective the answer to this
>>question
>> > depends on how ³interconnected² we feel that our releases are. If we
>>are
>> > releasing one thing that our users will consume as unified piece
>>(albeit
>> > broken to different modules), having single version make sense to me
>> (that
>> > is something in the line that Hadoop seems to be doing or to outside
>>of
>> > ASF, KDE is also doing). If we¹re expecting that our users will
>>consume
>> > only parts - e.g. for example only the audience-annotation part -
>>then in
>> > my mind, it would make sense to have them on separate release/version
>> > schedule.
>> >
>> > Just my 2 cents :)
>> >
>> > Jarcec
>> >
>> > > On Sep 23, 2015, at 7:55 AM, Sean Busbey <bu...@apache.org> wrote:
>> > >
>> > > On Wed, Sep 23, 2015 at 6:57 AM, Allen Wittenauer <aw...@altiscale.com>
>> > wrote:
>> > >>
>> > >>
>> > >> * versions tend to be tied to release artifacts:  I think we're
>>going
>> > to want one artifact of everything rather than four different
>>artifacts
>> > >>
>> > >
>> > > Any particular reason for this? It's easier to maintain our dist
>> > > directory that way. Also fewer/less complicated VOTE threads needed.
>> > > Actually, that might be enough to convince me. :)
>> > >
>> > >
>> > >> * if we release often enough, it won't matter that much if one part
>> > hasn't changed
>> > >
>> > > I had been thinking of this the opposite way; that if we release
>>often
>> > > we'll end up with many versions that are empty for some component
>>(in
>> > > particular audience-annotations).
>> > >
>> > > But I can't actually think of a problem with having "no changes in
>> > > this release" in the release note section on one or more components.
>> > >
>> > >
>> > >> * changes to the build system and repo layout will likely impact
>>all
>> > components anyway
>> > >
>> > > Are we going for a unified top-level build system? I hadn't even
>> > > considered. We should look at how painful / not-painful things are
>> > > over in Apache Avro then, since they're the closest I can think of
>>in
>> > > terms of having components with different build needs that have to
>>be
>> > > stitched together.
>> >
>> >
>>

Re: [DISCUSS] versioning components

[Mark Grover <ma...@apache.org>]

Yeah, my vote is to stick to one release version for now as well. Easier to
handle logistically and for our users to be able to say I am using YETUS
X.Y.Z. As we mature, perhaps we can reconsider this decision but I
personally have little motivation to vote for anything but 1 version number
for now.

On Wed, Sep 23, 2015 at 8:43 AM, Nick Dimiduk <nd...@apache.org> wrote:

> I think we should keep our lives simple by shipping one release artifact to
> begin with. I second the concern of burdening ourselves with 4x the VOTEs
> for every release. Most projects start with a lot of change in the
> beginning anyway, so it's likely that most of the components will be
> updated with each release. Once we've gotten into the swing of things, we
> can consider breaking the bundle apart.
>
> As another example of a project that stitches together multiple components
> in a single build process, have a look at HTrace.
>
> On Wed, Sep 23, 2015 at 8:11 AM, Jarek Jarcec Cecho <ja...@apache.org>
> wrote:
>
> > >> * if we release often enough, it won't matter that much if one part
> > hasn't changed
> > >
> > > I had been thinking of this the opposite way; that if we release often
> > > we'll end up with many versions that are empty for some component (in
> > > particular audience-annotations).
> > >
> > > But I can't actually think of a problem with having "no changes in
> > > this release" in the release note section on one or more components.
> >
> > I would like add few notes to this particular topic - I feel that it’s
> > always focusing for end user when there is a release of component that
> > doesn’t have any changes. From my perspective the answer to this question
> > depends on how “interconnected” we feel that our releases are. If we are
> > releasing one thing that our users will consume as unified piece (albeit
> > broken to different modules), having single version make sense to me
> (that
> > is something in the line that Hadoop seems to be doing or to outside of
> > ASF, KDE is also doing). If we’re expecting that our users will consume
> > only parts - e.g. for example only the audience-annotation part - then in
> > my mind, it would make sense to have them on separate release/version
> > schedule.
> >
> > Just my 2 cents :)
> >
> > Jarcec
> >
> > > On Sep 23, 2015, at 7:55 AM, Sean Busbey <bu...@apache.org> wrote:
> > >
> > > On Wed, Sep 23, 2015 at 6:57 AM, Allen Wittenauer <aw...@altiscale.com>
> > wrote:
> > >>
> > >>
> > >> * versions tend to be tied to release artifacts:  I think we're going
> > to want one artifact of everything rather than four different artifacts
> > >>
> > >
> > > Any particular reason for this? It's easier to maintain our dist
> > > directory that way. Also fewer/less complicated VOTE threads needed.
> > > Actually, that might be enough to convince me. :)
> > >
> > >
> > >> * if we release often enough, it won't matter that much if one part
> > hasn't changed
> > >
> > > I had been thinking of this the opposite way; that if we release often
> > > we'll end up with many versions that are empty for some component (in
> > > particular audience-annotations).
> > >
> > > But I can't actually think of a problem with having "no changes in
> > > this release" in the release note section on one or more components.
> > >
> > >
> > >> * changes to the build system and repo layout will likely impact all
> > components anyway
> > >
> > > Are we going for a unified top-level build system? I hadn't even
> > > considered. We should look at how painful / not-painful things are
> > > over in Apache Avro then, since they're the closest I can think of in
> > > terms of having components with different build needs that have to be
> > > stitched together.
> >
> >
>

Re: [DISCUSS] versioning components

[Nick Dimiduk <nd...@apache.org>]

I think we should keep our lives simple by shipping one release artifact to
begin with. I second the concern of burdening ourselves with 4x the VOTEs
for every release. Most projects start with a lot of change in the
beginning anyway, so it's likely that most of the components will be
updated with each release. Once we've gotten into the swing of things, we
can consider breaking the bundle apart.

As another example of a project that stitches together multiple components
in a single build process, have a look at HTrace.

On Wed, Sep 23, 2015 at 8:11 AM, Jarek Jarcec Cecho <ja...@apache.org>
wrote:

> >> * if we release often enough, it won't matter that much if one part
> hasn't changed
> >
> > I had been thinking of this the opposite way; that if we release often
> > we'll end up with many versions that are empty for some component (in
> > particular audience-annotations).
> >
> > But I can't actually think of a problem with having "no changes in
> > this release" in the release note section on one or more components.
>
> I would like add few notes to this particular topic - I feel that it’s
> always focusing for end user when there is a release of component that
> doesn’t have any changes. From my perspective the answer to this question
> depends on how “interconnected” we feel that our releases are. If we are
> releasing one thing that our users will consume as unified piece (albeit
> broken to different modules), having single version make sense to me (that
> is something in the line that Hadoop seems to be doing or to outside of
> ASF, KDE is also doing). If we’re expecting that our users will consume
> only parts - e.g. for example only the audience-annotation part - then in
> my mind, it would make sense to have them on separate release/version
> schedule.
>
> Just my 2 cents :)
>
> Jarcec
>
> > On Sep 23, 2015, at 7:55 AM, Sean Busbey <bu...@apache.org> wrote:
> >
> > On Wed, Sep 23, 2015 at 6:57 AM, Allen Wittenauer <aw...@altiscale.com>
> wrote:
> >>
> >>
> >> * versions tend to be tied to release artifacts:  I think we're going
> to want one artifact of everything rather than four different artifacts
> >>
> >
> > Any particular reason for this? It's easier to maintain our dist
> > directory that way. Also fewer/less complicated VOTE threads needed.
> > Actually, that might be enough to convince me. :)
> >
> >
> >> * if we release often enough, it won't matter that much if one part
> hasn't changed
> >
> > I had been thinking of this the opposite way; that if we release often
> > we'll end up with many versions that are empty for some component (in
> > particular audience-annotations).
> >
> > But I can't actually think of a problem with having "no changes in
> > this release" in the release note section on one or more components.
> >
> >
> >> * changes to the build system and repo layout will likely impact all
> components anyway
> >
> > Are we going for a unified top-level build system? I hadn't even
> > considered. We should look at how painful / not-painful things are
> > over in Apache Avro then, since they're the closest I can think of in
> > terms of having components with different build needs that have to be
> > stitched together.
>
>

Re: [DISCUSS] versioning components

[Jarek Jarcec Cecho <ja...@apache.org>]

>> * if we release often enough, it won't matter that much if one part hasn't changed
> 
> I had been thinking of this the opposite way; that if we release often
> we'll end up with many versions that are empty for some component (in
> particular audience-annotations).
> 
> But I can't actually think of a problem with having "no changes in
> this release" in the release note section on one or more components.

I would like add few notes to this particular topic - I feel that it’s always focusing for end user when there is a release of component that doesn’t have any changes. From my perspective the answer to this question depends on how “interconnected” we feel that our releases are. If we are releasing one thing that our users will consume as unified piece (albeit broken to different modules), having single version make sense to me (that is something in the line that Hadoop seems to be doing or to outside of ASF, KDE is also doing). If we’re expecting that our users will consume only parts - e.g. for example only the audience-annotation part - then in my mind, it would make sense to have them on separate release/version schedule.

Just my 2 cents :)

Jarcec

> On Sep 23, 2015, at 7:55 AM, Sean Busbey <bu...@apache.org> wrote:
> 
> On Wed, Sep 23, 2015 at 6:57 AM, Allen Wittenauer <aw...@altiscale.com> wrote:
>> 
>> 
>> * versions tend to be tied to release artifacts:  I think we're going to want one artifact of everything rather than four different artifacts
>> 
> 
> Any particular reason for this? It's easier to maintain our dist
> directory that way. Also fewer/less complicated VOTE threads needed.
> Actually, that might be enough to convince me. :)
> 
> 
>> * if we release often enough, it won't matter that much if one part hasn't changed
> 
> I had been thinking of this the opposite way; that if we release often
> we'll end up with many versions that are empty for some component (in
> particular audience-annotations).
> 
> But I can't actually think of a problem with having "no changes in
> this release" in the release note section on one or more components.
> 
> 
>> * changes to the build system and repo layout will likely impact all components anyway
> 
> Are we going for a unified top-level build system? I hadn't even
> considered. We should look at how painful / not-painful things are
> over in Apache Avro then, since they're the closest I can think of in
> terms of having components with different build needs that have to be
> stitched together.

Re: [DISCUSS] versioning components

[Sean Busbey <bu...@apache.org>]

On Wed, Sep 23, 2015 at 6:57 AM, Allen Wittenauer <aw...@altiscale.com> wrote:
>
>
> * versions tend to be tied to release artifacts:  I think we're going to want one artifact of everything rather than four different artifacts
>

Any particular reason for this? It's easier to maintain our dist
directory that way. Also fewer/less complicated VOTE threads needed.
Actually, that might be enough to convince me. :)


> * if we release often enough, it won't matter that much if one part hasn't changed

I had been thinking of this the opposite way; that if we release often
we'll end up with many versions that are empty for some component (in
particular audience-annotations).

But I can't actually think of a problem with having "no changes in
this release" in the release note section on one or more components.


> * changes to the build system and repo layout will likely impact all components anyway

Are we going for a unified top-level build system? I hadn't even
considered. We should look at how painful / not-painful things are
over in Apache Avro then, since they're the closest I can think of in
terms of having components with different build needs that have to be
stitched together.

Re: [DISCUSS] versioning components

[Allen Wittenauer <aw...@altiscale.com>]

On Sep 22, 2015, at 8:56 PM, Sean Busbey <bu...@apache.org> wrote:
> I've been presuming we'll version these independently, if only because
> I expect them to have different rates of change. One down side of this
> presumption is that we'd need to have component-specific versions in
> jira.
> 
> What do other folks think?


	I think we're going to want "one version to rule them all", at least in the beginning:

* versions tend to be tied to release artifacts:  I think we're going to want one artifact of everything rather than four different artifacts

* if we release often enough, it won't matter that much if one part hasn't changed

* changes to the build system and repo layout will likely impact all components anyway