More releases to encourage collaboration

[Ignasi Barrera <na...@apache.org>]

Hi!

There have been recent discussions about how jclouds could encourage
contributions. There were opinions to lower the barrier to become a
committer (among others), but I'd like to discuss our release cadence,
as I'm convinced improving it would directly benefit our community and
encourage more active contributions.

Currently it takes ages to release a jclouds version. We want
everything to be as good as possible and we set milestones that are
often not aligned with the needs of our users. I'd propose to forget
about fixed dates or minimum feature sets, and just release when it
makes sense.

I don't care about having a jclouds 2.0.59. If we can release jclouds
as soon as we have merged some patches to a particular provider that
fix a funtcional issue, or several minor patches that fix minor
internal issues, I'd say we should release. That will, in my opinion,
help tremendously in:

* Keeping users using the latest version, and upgrading would be
easier for them.
* They'll be happier since they will be able to fix their issues sooner.
* Will encourage contributions. If we merge patches and release soon,
contributors will see an immediate result and will be more keen on
contributing more patches.
* We would minimize things like this:
https://issues.sonatype.org/browse/OSSRH-25296

So, I'd reconsider our release cadence and release planning, and
release jclouds as soon as someone asks for it and we have a minimum
change set that makes sense.


I'd love to hear your opinions on this!

I.

Re: More releases to encourage collaboration

[Andrew Phillips <ap...@qrmedia.com>]

> Apart form that, we've been not backporting issues to 1.9.x for a
> while with the purpose of releasing 2.0 sooner, so I'd say we should
> not cut another 1.9.x.

Sounds good to me - thanks for explaining.

If there's anyone out there you would need a 1.9.x, please speak up!

ap

Re: More releases to encourage collaboration

[Ignasi Barrera <ig...@gmail.com>]

I'd say there are few significant breaking changes. For dependencies
we've kept backwards compatibility on all of them, and other breaking
changes shouldn't be a challenge.
Apart form that, we've been not backporting issues to 1.9.x for a
while with the purpose of releasing 2.0 sooner, so I'd say we should
not cut another 1.9.x.

The only issue regarding versions is the Gson 2.7 upgrade [1], but I'd
say upgrading is not critical/mandatory. Users can easily shade
jclouds with our gson dependency to workaround the issue.

I.


[1] https://issues.apache.org/jira/browse/JCLOUDS-1160

On 4 October 2016 at 17:23, Andrew Phillips <ap...@qrmedia.com> wrote:
>> I'd say... 2.0 this or next week! :D
>
>
> Nice! Would it make sense to consider a 1.9.2 too, however, for anyone who
> needs to stay on that branch? Or are there sufficiently few breaking changes
> in 2.x that we feel that's not necessary?
>
> Regards
>
> ap

Re: More releases to encourage collaboration

[Andrew Phillips <ap...@qrmedia.com>]

> I'd say... 2.0 this or next week! :D

Nice! Would it make sense to consider a 1.9.2 too, however, for anyone 
who needs to stay on that branch? Or are there sufficiently few breaking 
changes in 2.x that we feel that's not necessary?

Regards

ap

Re: More releases to encourage collaboration

[Ignasi Barrera <ig...@gmail.com>]

I'd say... 2.0 this or next week! :D

Andrea and I are working on finishing the remaining bits in the Azure
ARM provider and I'd say we should release 2.0 as soon as we're done
with it

On 4 October 2016 at 17:04, Andrew Phillips <ap...@qrmedia.com> wrote:
>> So, I'd reconsider our release cadence and release planning, and
>> release jclouds as soon as someone asks for it and we have a minimum
>> change set that makes sense.
>
>
> Apart from major releases, I fully agree that we should be releasing on an
> "as needed" basis, with a bias to releasing *more* rather than *less* often.
> That used to be painful purely from a procedural perspective, but with the
> great work you did on the script, that's hopefully no longer the case.
>
> From my vague recollections, the idea of a release cadence for non-major
> releases was also largely based on the anticipated overhead.
>
> 1.9.2 this or next week? ;-)
>
> Regards
>
> ap

Re: More releases to encourage collaboration

[Andrew Phillips <ap...@qrmedia.com>]

> So, I'd reconsider our release cadence and release planning, and
> release jclouds as soon as someone asks for it and we have a minimum
> change set that makes sense.

Apart from major releases, I fully agree that we should be releasing on 
an "as needed" basis, with a bias to releasing *more* rather than *less* 
often. That used to be painful purely from a procedural perspective, but 
with the great work you did on the script, that's hopefully no longer 
the case.

 From my vague recollections, the idea of a release cadence for non-major 
releases was also largely based on the anticipated overhead.

1.9.2 this or next week? ;-)

Regards

ap

Re: More releases to encourage collaboration

[Alex Heneveld <al...@cloudsoftcorp.com>]

Great idea Ignasi.  Speaking as a contributor it's sad when I offer a PR 
and it doesn't land in a release for many months.  Of course I 
understand the overhead in cutting a release and the desire to keep the 
bar high but I think the balance would be better served with frequent 
releases.  And thanks to the volunteers who are willing to make that happen!

--A


On 04/10/2016 17:29, Josef Cacek wrote:
> Absolutely +1
>
> Every fix/feature counts!
>
> Thanks,
>
> -- Josef
>
> ----- Original Message -----
>> From: "Andrea Turli" <an...@gmail.com>
>> To: dev@jclouds.apache.org
>> Sent: Tuesday, October 4, 2016 2:58:01 PM
>> Subject: Re: More releases to encourage collaboration
>>
>> +1 on more frequent releases!
>>
>> On Tue, Oct 4, 2016 at 2:13 PM, Ignasi Barrera <na...@apache.org> wrote:
>>
>>> Hi!
>>>
>>> There have been recent discussions about how jclouds could encourage
>>> contributions. There were opinions to lower the barrier to become a
>>> committer (among others), but I'd like to discuss our release cadence,
>>> as I'm convinced improving it would directly benefit our community and
>>> encourage more active contributions.
>>>
>>> Currently it takes ages to release a jclouds version. We want
>>> everything to be as good as possible and we set milestones that are
>>> often not aligned with the needs of our users. I'd propose to forget
>>> about fixed dates or minimum feature sets, and just release when it
>>> makes sense.
>>>
>>> I don't care about having a jclouds 2.0.59. If we can release jclouds
>>> as soon as we have merged some patches to a particular provider that
>>> fix a funtcional issue, or several minor patches that fix minor
>>> internal issues, I'd say we should release. That will, in my opinion,
>>> help tremendously in:
>>>
>>> * Keeping users using the latest version, and upgrading would be
>>> easier for them.
>>> * They'll be happier since they will be able to fix their issues sooner.
>>> * Will encourage contributions. If we merge patches and release soon,
>>> contributors will see an immediate result and will be more keen on
>>> contributing more patches.
>>> * We would minimize things like this:
>>> https://issues.sonatype.org/browse/OSSRH-25296
>>>
>>> So, I'd reconsider our release cadence and release planning, and
>>> release jclouds as soon as someone asks for it and we have a minimum
>>> change set that makes sense.
>>>
>>>
>>> I'd love to hear your opinions on this!
>>>
>>> I.
>>>

Re: More releases to encourage collaboration

[Josef Cacek <jc...@redhat.com>]

Absolutely +1

Every fix/feature counts!

Thanks,

-- Josef

----- Original Message -----
> From: "Andrea Turli" <an...@gmail.com>
> To: dev@jclouds.apache.org
> Sent: Tuesday, October 4, 2016 2:58:01 PM
> Subject: Re: More releases to encourage collaboration
> 
> +1 on more frequent releases!
> 
> On Tue, Oct 4, 2016 at 2:13 PM, Ignasi Barrera <na...@apache.org> wrote:
> 
> > Hi!
> >
> > There have been recent discussions about how jclouds could encourage
> > contributions. There were opinions to lower the barrier to become a
> > committer (among others), but I'd like to discuss our release cadence,
> > as I'm convinced improving it would directly benefit our community and
> > encourage more active contributions.
> >
> > Currently it takes ages to release a jclouds version. We want
> > everything to be as good as possible and we set milestones that are
> > often not aligned with the needs of our users. I'd propose to forget
> > about fixed dates or minimum feature sets, and just release when it
> > makes sense.
> >
> > I don't care about having a jclouds 2.0.59. If we can release jclouds
> > as soon as we have merged some patches to a particular provider that
> > fix a funtcional issue, or several minor patches that fix minor
> > internal issues, I'd say we should release. That will, in my opinion,
> > help tremendously in:
> >
> > * Keeping users using the latest version, and upgrading would be
> > easier for them.
> > * They'll be happier since they will be able to fix their issues sooner.
> > * Will encourage contributions. If we merge patches and release soon,
> > contributors will see an immediate result and will be more keen on
> > contributing more patches.
> > * We would minimize things like this:
> > https://issues.sonatype.org/browse/OSSRH-25296
> >
> > So, I'd reconsider our release cadence and release planning, and
> > release jclouds as soon as someone asks for it and we have a minimum
> > change set that makes sense.
> >
> >
> > I'd love to hear your opinions on this!
> >
> > I.
> >
> 

Re: More releases to encourage collaboration

[Andrea Turli <an...@gmail.com>]

+1 on more frequent releases!

On Tue, Oct 4, 2016 at 2:13 PM, Ignasi Barrera <na...@apache.org> wrote:

> Hi!
>
> There have been recent discussions about how jclouds could encourage
> contributions. There were opinions to lower the barrier to become a
> committer (among others), but I'd like to discuss our release cadence,
> as I'm convinced improving it would directly benefit our community and
> encourage more active contributions.
>
> Currently it takes ages to release a jclouds version. We want
> everything to be as good as possible and we set milestones that are
> often not aligned with the needs of our users. I'd propose to forget
> about fixed dates or minimum feature sets, and just release when it
> makes sense.
>
> I don't care about having a jclouds 2.0.59. If we can release jclouds
> as soon as we have merged some patches to a particular provider that
> fix a funtcional issue, or several minor patches that fix minor
> internal issues, I'd say we should release. That will, in my opinion,
> help tremendously in:
>
> * Keeping users using the latest version, and upgrading would be
> easier for them.
> * They'll be happier since they will be able to fix their issues sooner.
> * Will encourage contributions. If we merge patches and release soon,
> contributors will see an immediate result and will be more keen on
> contributing more patches.
> * We would minimize things like this:
> https://issues.sonatype.org/browse/OSSRH-25296
>
> So, I'd reconsider our release cadence and release planning, and
> release jclouds as soon as someone asks for it and we have a minimum
> change set that makes sense.
>
>
> I'd love to hear your opinions on this!
>
> I.
>