You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Everett Toews <ev...@RACKSPACE.COM> on 2014/08/29 14:51:15 UTC
2.0.0 in mid-Sept.
Hi All,
At our current release cadence we would reach 2.0.0 until Feb. 2015. I’d like to propose that we release 2.0.0 in mid-Sept. for a number of reasons.
1. A big boost in interest for jclouds at JavaOne
I’ll be giving an “Introduction to Apache jclouds” session at JavaOne on Sept. 30. I think we could get a big boost in interest for jclouds if I announce that we’ve gone to 2.0.0 and Java 7. Especially if we follow this up with an ASF press release shortly before or after.
2. Using Java 7
Now that we’ve committed to using Java 7 it would be good to release it too. It would also be nice if we release the Java 7 version of jclouds to our users more than a month before the Java 7 EOL in Apr. 2015. ;)
3. Makes development a bit easier
When back porting changes to 2.0.x branch we wouldn’t have to worry about accidentally back porting something that is Java 7 specific like we do with 1.8.x.
If people still need 1.8.1 then we can still release 1.8.1 alongside 2.0.0.
It terms of dates we could do the following.
Code freeze: Sept. 19
Release begins: Sept. 22
Let me know what you think.
Thanks,
Everett
Re: 2.0.0 in mid-Sept.
Posted by Everett Toews <ev...@RACKSPACE.COM>.
Alright. I figured an early 2.0.0 release was a bit of a long shot. Good discussion though. Let’s continue it on the “jclouds roadmap” thread.
Thanks,
Everett
On Sep 2, 2014, at 3:54 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
> TL;DR: I'm not against marketing releases as such, but I agree that a "big number" marketing release should have something reasonably significant going for it technically. I don't think we have that here, so I'm -1 at this point.
>
> Obviously, I'm in favour of doing everything we can to ensure jclouds gets as much attention as possible at JavaOne. I hope we can do that by highlighting all the cool new stuff in the latest release + more cool stuff on the roadmap, rather than having to resort to pulling a "2.0.0" out of the hat for that.
>
> In fact, I think it may be worth considering using names for releases that are not linked to version numbers, precisely to avoid the need to "get creative" with version numbers simply to make a release look big. Perhaps that's something we can incorporate into the ongoing discussion of which kind of versioning scheme we want to use moving forward.
>
> For me, "2.0.0", especially under the current versioning scheme where it's almost a "super-major" release, represents the last opportunity for a while to make pretty big changes, such as de-asyncing everything that can be asynced, pulling jclouds-chef into the main repo, and other Big Changes we have in mind.
>
> The open questions for me at this point are:
>
> * Do we really rely so much on "2.0.0" in order to get attention? Is there some way we can craft a message for JavaOne and other conferences that is appealing enough without having to resort to this?
> * What are actually all the Big Changes that we really want to make before pushing out a "super-major" release such as 2.0.0, i.e. is what's on the roadmap draft 1] accurate in any way? How long would it take to get these done?
>
> Regards
>
> ap
>
> [1] https://wiki.apache.org/jclouds/Roadmap
Re: 2.0.0 in mid-Sept.
Posted by Andrew Phillips <ap...@qrmedia.com>.
TL;DR: I'm not against marketing releases as such, but I agree that a
"big number" marketing release should have something reasonably
significant going for it technically. I don't think we have that here,
so I'm -1 at this point.
Obviously, I'm in favour of doing everything we can to ensure jclouds
gets as much attention as possible at JavaOne. I hope we can do that
by highlighting all the cool new stuff in the latest release + more
cool stuff on the roadmap, rather than having to resort to pulling a
"2.0.0" out of the hat for that.
In fact, I think it may be worth considering using names for releases
that are not linked to version numbers, precisely to avoid the need to
"get creative" with version numbers simply to make a release look big.
Perhaps that's something we can incorporate into the ongoing
discussion of which kind of versioning scheme we want to use moving
forward.
For me, "2.0.0", especially under the current versioning scheme where
it's almost a "super-major" release, represents the last opportunity
for a while to make pretty big changes, such as de-asyncing everything
that can be asynced, pulling jclouds-chef into the main repo, and
other Big Changes we have in mind.
The open questions for me at this point are:
* Do we really rely so much on "2.0.0" in order to get attention? Is
there some way we can craft a message for JavaOne and other
conferences that is appealing enough without having to resort to this?
* What are actually all the Big Changes that we really want to make
before pushing out a "super-major" release such as 2.0.0, i.e. is
what's on the roadmap draft 1] accurate in any way? How long would it
take to get these done?
Regards
ap
[1] https://wiki.apache.org/jclouds/Roadmap
Re: 2.0.0 in mid-Sept.
Posted by Chris Custine <ch...@gmail.com>.
Hi Everett,
I’m all for capitalizing on an opportunity to promote the project, and I wouldn’t be opposed to moving up the 2.0 release a bit as long as we have some solid updates and new provider offerings to make the release worthy of the 2.0 versioning. My only concerns would be making sure that we have completed the roadmap goals and since 2.0 is largely the same as 1.8, that we have enough time to watch and fix issues that may start to trickle in as users begin using 1.8.
I’m a bit late to the "release cadence” discussion and I probably need to review that thread another time or two, but I may be the only one who is not a fan of attempting scheduled releases of Apache projects. With all of the moving parts and contributors from different companies, all with different levels of availability, and focus, a predictable schedule will be tough to achieve at times, whereas logically laid out feature roadmaps will evolve in a more organic way and help trigger release discussions as the roadmap items are checked off. And of course, the roadmap can and will change based on community discussions.
So I’m fine with moving up releases as long as they have the roadmap items agreed upon by the community. Scheduled releases are only going to bring pain, misery, and conflict IMHO. Obviously each project has a different set of dynamics, but this has been my experience on almost all Apache projects I work on :-)
--
Chris Custine
On August 29, 2014 at 6:51:44 AM, Everett Toews (everett.toews@rackspace.com) wrote:
Hi All,
At our current release cadence we would reach 2.0.0 until Feb. 2015. I’d like to propose that we release 2.0.0 in mid-Sept. for a number of reasons.
1. A big boost in interest for jclouds at JavaOne
I’ll be giving an “Introduction to Apache jclouds” session at JavaOne on Sept. 30. I think we could get a big boost in interest for jclouds if I announce that we’ve gone to 2.0.0 and Java 7. Especially if we follow this up with an ASF press release shortly before or after.
2. Using Java 7
Now that we’ve committed to using Java 7 it would be good to release it too. It would also be nice if we release the Java 7 version of jclouds to our users more than a month before the Java 7 EOL in Apr. 2015. ;)
3. Makes development a bit easier
When back porting changes to 2.0.x branch we wouldn’t have to worry about accidentally back porting something that is Java 7 specific like we do with 1.8.x.
If people still need 1.8.1 then we can still release 1.8.1 alongside 2.0.0.
It terms of dates we could do the following.
Code freeze: Sept. 19
Release begins: Sept. 22
Let me know what you think.
Thanks,
Everett
Re: 2.0.0 in mid-Sept.
Posted by Ignasi Barrera <na...@apache.org>.
Hi!
It took me a while to re-read the entire release cadence thread, to
answer this with but in the end I found some time :)
After thinking about it, I have to disagree with the proposed date.
Everett, I know I previously said I was OK with the proposal, but
after reading the entire thread and thinking more about it, I believe
we should wait (my apologies if this causes trouble), for several
reasons:
* We already have "announced" the 2.0.0 release date in the Roadmap
page [1]. Yes, it says January and not February, but we'd better delay
it one month than advancing it four. All the effort we're putting in
predictability, would be wasted if we change what we have been
announcing for at least two months (that's what the page history
says).
* We can announce 1.8 there. I think the big impact is caused by big
new features and not by a big number. We have the opportunity to
announce (and demo?) Docker and SoftLayer. I'm pretty sure that Docker
will bring much more attention than putting the "2" as the major
digit. We did a blog post and some tweets, but it would be great to
give to our latest major (1.8) a good announce there based on its key
new features.
* We can share our roadmap and plan for 2.0. This way we can show the
world that jclouds has a hie roadmap with new challenges for the next
major. Coming up: use of Java 7 in 2.0, etc, etc. We can show the
project already has some ambitious plans for the 2.0 release and we
can engage people and make them stay tuned.
* I'm also introducing jclouds at ApacheCon this November, and that
would be also a great event that could justify a major version. With
the given arguments, why not? I personally think there is no benefit
in such marketing releases. as I said before I think people is more
impressed and attracted by the key features that are presented than by
a major number, and specially if you can present an ambitious plan for
what's coming up.
I.
[1] https://wiki.apache.org/jclouds/Roadmap
On 31 August 2014 22:02, Everett Toews <ev...@rackspace.com> wrote:
> On Aug 30, 2014, at 2:34 PM, Andrew Gaul <ga...@apache.org> wrote:
>
>> Why should we release 2.0 out of step with the agreed-upon major release
>> cadence? If we cannot follow our own policy for the first release after
>> agreeing upon a policy, what confidence does that give our users in
>> subsequent releases, or in future policies?
>
> This is certainly a potential consequence of my proposal and is something we could bring up on the user list. We could ask our users how they would feel about such a move.
>
>> Users are not impressed by
>> big, round version numbers and jclouds is unlikely to realize a big
>> boost in interest due to 2.0.
>
> I disagree. Notice how Google announced Android L (big round version letter in this case) at Google I/O and Apple announced iOS 7 at WWDC. Another recent instance is Docker announcing Docker 1.0 at DockerCon. Obviously this isn’t a coincidence.
>
> At these conferences they have the undivided attention of developers for a brief time. A rare thing. Making such announcements of big round version numbers helps them gain mind share/market share.
>
>> What benefit do you believe that announcing dropping Java 6 provides?
>
> Reread my proposal. I am not emphasizing dropping Java 6. I am emphasizing the use of Java 7. There’s a big difference.
>
> For a brief time, I too will have the undivided attention of many Java developers. I hope to make an impression and gain more users and maybe even pique the interest of potential contributors. Demonstrating that we’ve moved on to Java 7 with a major release will enable this.
>
>> Instead of creating an artificial marketing release,
>
> I certainly agree that this is a marketing driven release.
>
>> perhaps we could
>> announce Amazon Glacier and soon Google Cloud Storage providers, which
>> completes our support for all major object stores? Or announce the new
>> Docker provider and improved SoftLayer support? Users have long
>> requested some of these providers and delivering them is something
>> tangible to crow about.
>
> Definitely. I love making these kinds of announcements. This is all good stuff that I’ll be including.
>
> Thanks,
> Everett
>
Re: 2.0.0 in mid-Sept.
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Aug 30, 2014, at 2:34 PM, Andrew Gaul <ga...@apache.org> wrote:
> Why should we release 2.0 out of step with the agreed-upon major release
> cadence? If we cannot follow our own policy for the first release after
> agreeing upon a policy, what confidence does that give our users in
> subsequent releases, or in future policies?
This is certainly a potential consequence of my proposal and is something we could bring up on the user list. We could ask our users how they would feel about such a move.
> Users are not impressed by
> big, round version numbers and jclouds is unlikely to realize a big
> boost in interest due to 2.0.
I disagree. Notice how Google announced Android L (big round version letter in this case) at Google I/O and Apple announced iOS 7 at WWDC. Another recent instance is Docker announcing Docker 1.0 at DockerCon. Obviously this isn’t a coincidence.
At these conferences they have the undivided attention of developers for a brief time. A rare thing. Making such announcements of big round version numbers helps them gain mind share/market share.
> What benefit do you believe that announcing dropping Java 6 provides?
Reread my proposal. I am not emphasizing dropping Java 6. I am emphasizing the use of Java 7. There’s a big difference.
For a brief time, I too will have the undivided attention of many Java developers. I hope to make an impression and gain more users and maybe even pique the interest of potential contributors. Demonstrating that we’ve moved on to Java 7 with a major release will enable this.
> Instead of creating an artificial marketing release,
I certainly agree that this is a marketing driven release.
> perhaps we could
> announce Amazon Glacier and soon Google Cloud Storage providers, which
> completes our support for all major object stores? Or announce the new
> Docker provider and improved SoftLayer support? Users have long
> requested some of these providers and delivering them is something
> tangible to crow about.
Definitely. I love making these kinds of announcements. This is all good stuff that I’ll be including.
Thanks,
Everett
Re: 2.0.0 in mid-Sept.
Posted by Andrew Gaul <ga...@apache.org>.
-1, I see little benefit to accelerating 2.0 or announcing dropping Java
6 support.
Why should we release 2.0 out of step with the agreed-upon major release
cadence? If we cannot follow our own policy for the first release after
agreeing upon a policy, what confidence does that give our users in
subsequent releases, or in future policies? Users are not impressed by
big, round version numbers and jclouds is unlikely to realize a big
boost in interest due to 2.0.
What benefit do you believe that announcing dropping Java 6 provides?
We removed support to make development of jclouds easier and reduce our
support matrix. We have only merged two small features which take
advantage of Java 7; users will not see many differences when upgrading.
Instead of creating an artificial marketing release, perhaps we could
announce Amazon Glacier and soon Google Cloud Storage providers, which
completes our support for all major object stores? Or announce the new
Docker provider and improved SoftLayer support? Users have long
requested some of these providers and delivering them is something
tangible to crow about.
Counter-proposal, we proceed with releases as we have since 1.6.0:
1.8.1 15-Sep-2014
1.8.2 01-Nov-2014
1.8.3 15-Dec-2014
2.0.0 01-Feb-2014
On Fri, Aug 29, 2014 at 12:51:15PM +0000, Everett Toews wrote:
> Hi All,
>
> At our current release cadence we would reach 2.0.0 until Feb. 2015. I’d like to propose that we release 2.0.0 in mid-Sept. for a number of reasons.
>
> 1. A big boost in interest for jclouds at JavaOne
>
> I’ll be giving an “Introduction to Apache jclouds” session at JavaOne on Sept. 30. I think we could get a big boost in interest for jclouds if I announce that we’ve gone to 2.0.0 and Java 7. Especially if we follow this up with an ASF press release shortly before or after.
>
> 2. Using Java 7
>
> Now that we’ve committed to using Java 7 it would be good to release it too. It would also be nice if we release the Java 7 version of jclouds to our users more than a month before the Java 7 EOL in Apr. 2015. ;)
>
> 3. Makes development a bit easier
>
> When back porting changes to 2.0.x branch we wouldn’t have to worry about accidentally back porting something that is Java 7 specific like we do with 1.8.x.
>
>
> If people still need 1.8.1 then we can still release 1.8.1 alongside 2.0.0.
>
> It terms of dates we could do the following.
>
> Code freeze: Sept. 19
> Release begins: Sept. 22
>
> Let me know what you think.
>
> Thanks,
> Everett
--
Andrew Gaul
http://gaul.org/