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/20 00:36:58 UTC
Re: major release cadence
Let’s see what we can agree on and move forward on those points.
1. 6 month major release cadence.
That would mean the next releases are roughly:
* 2.0.0 mid-Sept
* 2.1.0 early-Nov
* 2.2.0 late-Dec
* 2.3.0 mid-Feb
* 3.0.0 early-Mar
2. Minor point upgrades do not introduce breaking changes. e.g. "users upgrading from an earlier 3.x should be able to use a later
3.x release without source modification.” (pasted from Gaul’s previous email below).
Can everyone agree on those two points?
Regards,
Everett
On Jul 11, 2014, at 11:45 PM, Everett Toews <ev...@rackspace.com> wrote:
> On Jul 7, 2014, at 6:53 PM, Andrew Gaul <ga...@apache.org> wrote:
>
>> Sorry, I still do not understand and cannot reconcile these paragraphs
>> against earlier mails. Do we branch from master every six months or
>> not?
>
> Yes, we branch every 6 months.
>
>> Do we increase the major version every six months?
>
> Yes, we increment the major version every 6 months.
>
>> From your
>> example, it appears that we create a 3.x branch from master and continue
>> releasing 3.x from there.
>
> I think I see the confusion here. Trying to use text to communicate this was a bad idea. Maybe this diagram clears it up. It’s really not that much different than what we do now except for the major (instead of minor) release cadence.
>
> https://docs.google.com/drawings/d/1TDcsLyYPhWpcYEoNo8ohH9AMlpXJB3ywp1CzYCY9C38/edit?usp=sharing
>
>> This runs counter to my previous
>> understanding that master would be 3.x until we branched for the first
>> breaking change.
>>
>> Also I want to expand your example to explain how this will hurt
>> development on master, specifically diking out bad code. Imagine you
>> want to removing something like InputStreamMap after 3.0 releases:
>>
>> 3.0
>> 3.1 - deprecate older API in master
>> 3.x
>> 4.0 - master branches to 4.x, commit removal to master
>> 4.x
>> 5.x - removal ships to users
>>
>> In this example, we delay committing the removal to master for almost
>> six months (from 3.1 to 4.0) and delay communicating preferred
>> mechanisms on the release branch for the same interval. Changes are not
>> isolated and earlier changes block subsequent work, e.g., removing
>> InputStreamMap enabled some ByteSource changes. Not being able to push
>> these changes to master will make development much harder. Use of extra
>> development branches partially addresses this, although does not publish
>> these changes to all developers.
>
> I’m aware of this scenario and I would argue that it can be mitigated by better planning. If the deprecation and been well planned, it would have landed just prior to 3.0 and then the removal ships to users in 4.0. I realize that historically we haven’t been very good at planning but I don’t think that’s a good reason to not try to get better at this stuff.
>
>>> Not having a predictable deprecation policy guarantees that users will be more likely to stay marooned on old versions because they’ll have no idea at what point things will break on them.
>>
>> Perhaps we did not communicate this clearly, but jclouds has had a
>> predictable deprecation policy for at least the last three years. Users
>> can upgrade from an earlier 1.7.x release to a later 1.7 release and
>> breaking changes were only introduced in 1.8.0. Sometimes a given 1.7.x
>> release contained new deprecation annotations but otherwise applications
>> continue to work. Despite this, users choose not to upgrade to the
>> latest micro releases.
>
> When you follow something reasonably close to semver you don’t have to worry about this kind of communication because everybody already knows it. Every time I encounter a new project I automatically assume semver unless it’s otherwise stated because there’s really no alternative assumption to make. I’d argue that this is what most developers do.
>
>>> I think making potentially breaking changes every 6 months is actually very progressive in the world of Java. I think it’s a good trade off between providing a stable and predictable platform for users to build the businesses upon vs improving that platform in backwards incompatible ways.
>>
>> I believe that providing flexibility to evolve jclouds will benefit our
>> future users as well as existing ones. Shackling ourselves to
>> restrictive deprecation policies hurts a fair number of people who
>> prefer to use a more rational cloud abstraction.
>
> Just as throwing it open to making deprecations at any point hurts a fair number of people who prefer to use a more stable and predictable cloud abstraction.
>
>> I believe some
>> positive changes simply will not happen with the proposed system.
>>
>> In the interests of not talking past each other, I want to summarize
>> some points in this thread as I understand them.
>
> Thanks for this. Agreed that we need to focus the discussion a bit more. So I’m only going to reply to this email to keep us on one email thread.
>
>> First, we all agree
>> that users upgrading from an earlier 3.x should be able to use a later
>> 3.x release without source modification.
>
> Yes. Agreed.
>
>> We disagree whether users
>> should experience new deprecation warnings when upgrading.
>
> Yes. We disagree. My main point of contention here is that there needs to be a minimum amount of time for users to react to changes.
>
> You feel that 6 weeks is acceptable, such as in the case of 3.3 to 4.0.
>
> I feel that 6 weeks is far too short and have been arguing for 6 months.
>
>> Second, we
>> disagree whether users should experience breaking changes when upgrading
>> from 3.x to 4.x.
>
> I’m not so sure we disagree here. Because users are upgrading across a major release boundary there could be breaking changes.
>
> But breaking changes should only be in 4.0 and *not* in 4.1, 4.2, or 4.3.
>
>> We agree that users can experience breakages from 2.x
>> to 4.x, with some intermediate deprecations.
>
> Yes. We agree (with my same caveat about breaking changes above).
>
>> Lastly we disagree on
>> whether master can introduce breaking changes at any point, or only
>> after some branching a major release from master.
>
> Yes. We disagree. This goes back to my main point of contention.
>
> Again, to me it really seems like the BlobStore is your main concern for being able to break things more quickly in order to rapidly improve the existing code. The ComputeService and other APIs don’t seem to be in such a state in general.
>
> What if you could work on the BlobStore and deprecate at any point between 2.0 and 3.0?
>
> If the BlobStore API had stabilized by 3.0 then perhaps it could move to the more conservative deprecation proposal. Thoughts?
>
> Regards,
> Everett
>
>
RE: major release cadence
Posted by Martin Smith <ma...@RACKSPACE.COM>.
Hi folks,
I agree that changing from 1.major.minor to major.minor would be confusing for users. I don't really have a horse in this race, but if I were trying to make a move from 1.major.minor to major.minor, I'd do it like the Java versions, so that users might have a chance at being familiar with it. For example,
old scheme -> new scheme
1.7.0 -> 7.0.0
1.8.0 -> 8.0.0
etc
So if the project *must* renumber closer to semver (dropping the leading "1." in front of every version), then at least users will be familiar with it that are familiar with Java version numbers (though unlike Oracle, I'd eventually try to drop the 1.x designations).
I don't really have strong feelings about the actual change. Just something I was thinking about while reading the thread. Hope it's a useful observation!
- Martin Smith
martin@mbs3.org
________________________________________
From: Andrew Gaul [gaul@apache.org]
Sent: Monday, August 25, 2014 11:00 AM
To: dev@jclouds.apache.org
Subject: Re: major release cadence
On Sun, Aug 24, 2014 at 02:28:18PM +0200, Andrew Phillips wrote:
> >Given the lack of positive feedback to semantic versioning
>
> Sorry, a bit behind in catching up with emails. To me, the rough
> timing of releases and decision on breaking changes are indeed the
> main two points, which seem fine to me.
Prior to this thread we introduced breaking changes in major releases,
as defined by 1.7 -> 1.8, and released minor releases, as defined by
1.7.0 -> 1.7.1, every 6-8 weeks. Earlier in this thread we agreed to
major releases every 6 months, again defined as 1.7 -> 1.8.
> I'm also fine with semantic versioning, but agree that we can move
> forward on the former two points and leave this for later if
> necessary. I don't immediately see any obvious areas where the
> transition cost would be that big.
>
> Could you elaborate on the challenges you see there, Andrew G?
If we were starting a new project, I would not care as much for which
versioning scheme we chose. However, we have an existing practice which
developers and users already understand and I see benefits to continuing
for consistency, outweighing the purported and modest benefits of other
schemes. Specifically, users expect today that X.Y+1.0 upgrades can
introduce breaking changes and delay upgrading to these releases.
Changing this requires messaging to our users, similar to other
transitions with source control, bug tracking, and mailing lists.
Further other projects have changed versioning schemes, such as Firefox
and Java, which caused user confusion without discernible benefit.
--
Andrew Gaul
http://gaul.org/
Re: major release cadence
Posted by Andrew Gaul <ga...@apache.org>.
On Sun, Aug 24, 2014 at 02:28:18PM +0200, Andrew Phillips wrote:
> >Given the lack of positive feedback to semantic versioning
>
> Sorry, a bit behind in catching up with emails. To me, the rough
> timing of releases and decision on breaking changes are indeed the
> main two points, which seem fine to me.
Prior to this thread we introduced breaking changes in major releases,
as defined by 1.7 -> 1.8, and released minor releases, as defined by
1.7.0 -> 1.7.1, every 6-8 weeks. Earlier in this thread we agreed to
major releases every 6 months, again defined as 1.7 -> 1.8.
> I'm also fine with semantic versioning, but agree that we can move
> forward on the former two points and leave this for later if
> necessary. I don't immediately see any obvious areas where the
> transition cost would be that big.
>
> Could you elaborate on the challenges you see there, Andrew G?
If we were starting a new project, I would not care as much for which
versioning scheme we chose. However, we have an existing practice which
developers and users already understand and I see benefits to continuing
for consistency, outweighing the purported and modest benefits of other
schemes. Specifically, users expect today that X.Y+1.0 upgrades can
introduce breaking changes and delay upgrading to these releases.
Changing this requires messaging to our users, similar to other
transitions with source control, bug tracking, and mailing lists.
Further other projects have changed versioning schemes, such as Firefox
and Java, which caused user confusion without discernible benefit.
--
Andrew Gaul
http://gaul.org/
Re: major release cadence
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Please familiarize yourself with existing jclouds versioning scheme,
> which I will summarize.
Thanks for putting this together, Gaul! Maybe it's just me, but I get
a feeling we're actually having two discussions at once here, and it
might make sense to split them:
1. We can make life easier for our users (and new committers!) by
better documenting our deprecation policy and release cadence.
2. Does our current deprecation policy and versioning scheme make
sense, and do we want to change them?
From what I can see, the former discussion is not really contentious.
I'm pretty sure users will not automatically *look* at the deprecation
policy, and I think good Javadocs are much more critical here. But
it's something we can refer to in release notes and point to for new
committers, and so I think it would be useful.
Publishing a release cadence also seems like a no-brainer: users have
repeatedly asked for this, and I think minor releases at 6-week
intervals seemed acceptable.
The second topic is more contentious. My take is roughly that the
debate is essentially "benefit in terms of predictability of sticking
with the current scheme" vs. "benefit of moving to a different scheme
that is probably more widely adopted elsewhere". Or, looked at a
slightly different way, "predictability for existing users vs.
predictability for new users".
I don't recall seeing any direct user requests or questions in this
area, so I personally find it harder to come down on either side of
this debate at this point.
My suggestion would be:
1) We document the release cadence and deprecation policy as it is
*right now*. We have to decide on a place for that, but the Wiki seems
as good a place as any. We already have [1] and would then need to add
a Release Cadence/Roadmap page. For the version numbers in the
Roadmap, we would stick with the current scheme or simply say "MAJOR"
and "MINOR" with something like "(provisionally 2.1.0)" or so next to
the versions.
2) We continue the discussion about *modifying* the deprecation policy
and versioning schemes as needed:
a) removing deprecated code in MAJOR+2 vs. MAJOR+1 as currently
b) moving from MAJOR = X.Y.0, MINOR = X.Y.Z to MAJOR = X.0.0, MINOR =
X.Y.0, PATCH = X.Y.Z
Regards
ap
[1] https://wiki.apache.org/jclouds/DeprecationAndBetaPolicy
Re: major release cadence
Posted by Andrew Gaul <ga...@apache.org>.
On Sun, Aug 24, 2014 at 12:22:42PM +0000, Everett Toews wrote:
> You’ve completely lost me at this point. You’ve even introduced new jargon. What’s a micro release?
>
> And I have no idea what "major" means to you. To the majority of people in the software industry a major release means incrementing the first number in the version. It seems you’ve overloaded the term major as its already commonly used in semver. But semver aside, what does “major” mean to you in this context?
>
> Can you please provide an example of the version numbers for the next 6 months?
Please familiarize yourself with existing jclouds versioning scheme,
which I will summarize. We have released jclouds major versions
branched from master as 1.6, 1.7, and 1.8. We have also released
jclouds minor versions from release branches as 1.7.1, 1.7.2, and 1.7.3.
Major versions introduce breaking changes while minor versions do not.
We have not incremented the leading version number in almost four
years[1][2] but despite this we refer to 1.7 as a major release and
1.7.1 as a minor release. Whatever you believe about the "majority of
software engineers" does not apply to our practices and no one has
expressed confusion on this matter, other than that which you have
introduced in this thread.
To plan future releases, look back at the existing releases. I have
summarized all the ASF releases with a few pre-ASF releases for context.
Consider both the major and minor releases, including cadence:
1.6.0/ 27-Apr-2013
1.6.1-incubating/ 20-Jun-2013 7 weeks
1.6.2-incubating/ 27-Aug-2013 9 weeks
1.6.3/ 30-Nov-2013 12 weeks
1.7.0/ 23-Dec-2013 4 weeks
1.7.1/ 11-Feb-2014 7 weeks
1.7.2/ 15-Apr-2014 8 weeks
1.7.3/ 30-May-2014 6 weeks
1.8.0/ 05-Aug-2014 9 weeks
Also consider only the major releases, including cadence:
1.5.0/ 17-Sep-2012
1.6.0/ 27-Apr-2013 7 months
1.7.0/ 23-Dec-2013 6 months
1.8.0/ 05-Aug-2014 8 months
Following the existing 6 weeks minor release cadence and including the 6
month major release cadence we agreed to earlier in this thread, we can
plan the following major and minor releases:
1.8.1/ 15-Sep-2014 6 weeks
1.8.2/ 01-Nov-2014 6 weeks
1.8.3/ 15-Dec-2014 6 weeks
2.0.0/ 01-Feb-2014 6 weeks
Note that we only deviated in increasing the leading version number in
2.0 to address your suggestion for the new Java 7 dependency. Had we
not followed this suggestion, we would have released jclouds 1.9
instead, avoiding your confusion about "major" version numbers entirely.
[1] http://repo1.maven.org/maven2/org/jclouds/jclouds-project/
[2] http://repo1.maven.org/maven2/org/apache/jclouds/jclouds-project/
--
Andrew Gaul
http://gaul.org/
Re: major release cadence
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Aug 23, 2014, at 4:08 PM, Andrew Gaul <ga...@apache.org> wrote:
> You explicitly used semvar-style version numbers. Is this an implicit
> part of your proposal?
Nope.
> We already agreed to a six-month major release
> cadence and already do not break compatibility between minor (micro)
> releases. What exactly do you propose other than using these new-style
> version numbers?
You’ve completely lost me at this point. You’ve even introduced new jargon. What’s a micro release?
And I have no idea what "major" means to you. To the majority of people in the software industry a major release means incrementing the first number in the version. It seems you’ve overloaded the term major as its already commonly used in semver. But semver aside, what does “major” mean to you in this context?
Can you please provide an example of the version numbers for the next 6 months?
Everett
Re: major release cadence
Posted by Andrew Gaul <ga...@apache.org>.
On Sat, Aug 23, 2014 at 08:41:53PM +0000, Everett Toews wrote:
> On Aug 23, 2014, at 1:23 PM, Andrew Gaul <ga...@apache.org> wrote:
> > Given the lack of positive feedback to semantic versioning perhaps we
> > should table your proposal until you can convince other developers of
> > its benefits? I do not exactly oppose this idea, but I see its
> > advantages as modest and smaller then the transition costs.
>
> Note that neither of the points below having anything to do with semver whatsoever.
>
> In fact, the first point is the original purpose of this thread that you started, choosing a major release cadence. The second point was quoted directly from you, regarding minor point upgrades.
>
> This is the common ground we agree on and I thought we could move forward on these 2 points alone for the sake of progress. Do you have any arguments for or against the 2 points below?
You explicitly used semvar-style version numbers. Is this an implicit
part of your proposal? We already agreed to a six-month major release
cadence and already do not break compatibility between minor (micro)
releases. What exactly do you propose other than using these new-style
version numbers?
--
Andrew Gaul
http://gaul.org/
Re: major release cadence
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Given the lack of positive feedback to semantic versioning
Sorry, a bit behind in catching up with emails. To me, the rough
timing of releases and decision on breaking changes are indeed the
main two points, which seem fine to me.
I'm also fine with semantic versioning, but agree that we can move
forward on the former two points and leave this for later if
necessary. I don't immediately see any obvious areas where the
transition cost would be that big.
Could you elaborate on the challenges you see there, Andrew G?
Regards
ap
Re: major release cadence
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Aug 23, 2014, at 1:23 PM, Andrew Gaul <ga...@apache.org> wrote:
> Given the lack of positive feedback to semantic versioning perhaps we
> should table your proposal until you can convince other developers of
> its benefits? I do not exactly oppose this idea, but I see its
> advantages as modest and smaller then the transition costs.
Note that neither of the points below having anything to do with semver whatsoever.
In fact, the first point is the original purpose of this thread that you started, choosing a major release cadence. The second point was quoted directly from you, regarding minor point upgrades.
This is the common ground we agree on and I thought we could move forward on these 2 points alone for the sake of progress. Do you have any arguments for or against the 2 points below?
> On Tue, Aug 19, 2014 at 10:36:58PM +0000, Everett Toews wrote:
>> Let’s see what we can agree on and move forward on those points.
>>
>> 1. 6 month major release cadence.
>>
>> That would mean the next releases are roughly:
>>
>> * 2.0.0 mid-Sept
>> * 2.1.0 early-Nov
>> * 2.2.0 late-Dec
>> * 2.3.0 mid-Feb
>> * 3.0.0 early-Mar
>>
>> 2. Minor point upgrades do not introduce breaking changes. e.g. "users upgrading from an earlier 3.x should be able to use a later
>> 3.x release without source modification.” (pasted from Gaul’s previous email below).
>>
>> Can everyone agree on those two points?
>>
>> Regards,
>> Everett
Re: major release cadence
Posted by Andrew Gaul <ga...@apache.org>.
Given the lack of positive feedback to semantic versioning perhaps we
should table your proposal until you can convince other developers of
its benefits? I do not exactly oppose this idea, but I see its
advantages as modest and smaller then the transition costs.
On Tue, Aug 19, 2014 at 10:36:58PM +0000, Everett Toews wrote:
> Let’s see what we can agree on and move forward on those points.
>
> 1. 6 month major release cadence.
>
> That would mean the next releases are roughly:
>
> * 2.0.0 mid-Sept
> * 2.1.0 early-Nov
> * 2.2.0 late-Dec
> * 2.3.0 mid-Feb
> * 3.0.0 early-Mar
>
> 2. Minor point upgrades do not introduce breaking changes. e.g. "users upgrading from an earlier 3.x should be able to use a later
> 3.x release without source modification.” (pasted from Gaul’s previous email below).
>
> Can everyone agree on those two points?
>
> Regards,
> Everett
>
>
>
> On Jul 11, 2014, at 11:45 PM, Everett Toews <ev...@rackspace.com> wrote:
>
> > On Jul 7, 2014, at 6:53 PM, Andrew Gaul <ga...@apache.org> wrote:
> >
> >> Sorry, I still do not understand and cannot reconcile these paragraphs
> >> against earlier mails. Do we branch from master every six months or
> >> not?
> >
> > Yes, we branch every 6 months.
> >
> >> Do we increase the major version every six months?
> >
> > Yes, we increment the major version every 6 months.
> >
> >> From your
> >> example, it appears that we create a 3.x branch from master and continue
> >> releasing 3.x from there.
> >
> > I think I see the confusion here. Trying to use text to communicate this was a bad idea. Maybe this diagram clears it up. It’s really not that much different than what we do now except for the major (instead of minor) release cadence.
> >
> > https://docs.google.com/drawings/d/1TDcsLyYPhWpcYEoNo8ohH9AMlpXJB3ywp1CzYCY9C38/edit?usp=sharing
> >
> >> This runs counter to my previous
> >> understanding that master would be 3.x until we branched for the first
> >> breaking change.
> >>
> >> Also I want to expand your example to explain how this will hurt
> >> development on master, specifically diking out bad code. Imagine you
> >> want to removing something like InputStreamMap after 3.0 releases:
> >>
> >> 3.0
> >> 3.1 - deprecate older API in master
> >> 3.x
> >> 4.0 - master branches to 4.x, commit removal to master
> >> 4.x
> >> 5.x - removal ships to users
> >>
> >> In this example, we delay committing the removal to master for almost
> >> six months (from 3.1 to 4.0) and delay communicating preferred
> >> mechanisms on the release branch for the same interval. Changes are not
> >> isolated and earlier changes block subsequent work, e.g., removing
> >> InputStreamMap enabled some ByteSource changes. Not being able to push
> >> these changes to master will make development much harder. Use of extra
> >> development branches partially addresses this, although does not publish
> >> these changes to all developers.
> >
> > I’m aware of this scenario and I would argue that it can be mitigated by better planning. If the deprecation and been well planned, it would have landed just prior to 3.0 and then the removal ships to users in 4.0. I realize that historically we haven’t been very good at planning but I don’t think that’s a good reason to not try to get better at this stuff.
> >
> >>> Not having a predictable deprecation policy guarantees that users will be more likely to stay marooned on old versions because they’ll have no idea at what point things will break on them.
> >>
> >> Perhaps we did not communicate this clearly, but jclouds has had a
> >> predictable deprecation policy for at least the last three years. Users
> >> can upgrade from an earlier 1.7.x release to a later 1.7 release and
> >> breaking changes were only introduced in 1.8.0. Sometimes a given 1.7.x
> >> release contained new deprecation annotations but otherwise applications
> >> continue to work. Despite this, users choose not to upgrade to the
> >> latest micro releases.
> >
> > When you follow something reasonably close to semver you don’t have to worry about this kind of communication because everybody already knows it. Every time I encounter a new project I automatically assume semver unless it’s otherwise stated because there’s really no alternative assumption to make. I’d argue that this is what most developers do.
> >
> >>> I think making potentially breaking changes every 6 months is actually very progressive in the world of Java. I think it’s a good trade off between providing a stable and predictable platform for users to build the businesses upon vs improving that platform in backwards incompatible ways.
> >>
> >> I believe that providing flexibility to evolve jclouds will benefit our
> >> future users as well as existing ones. Shackling ourselves to
> >> restrictive deprecation policies hurts a fair number of people who
> >> prefer to use a more rational cloud abstraction.
> >
> > Just as throwing it open to making deprecations at any point hurts a fair number of people who prefer to use a more stable and predictable cloud abstraction.
> >
> >> I believe some
> >> positive changes simply will not happen with the proposed system.
> >>
> >> In the interests of not talking past each other, I want to summarize
> >> some points in this thread as I understand them.
> >
> > Thanks for this. Agreed that we need to focus the discussion a bit more. So I’m only going to reply to this email to keep us on one email thread.
> >
> >> First, we all agree
> >> that users upgrading from an earlier 3.x should be able to use a later
> >> 3.x release without source modification.
> >
> > Yes. Agreed.
> >
> >> We disagree whether users
> >> should experience new deprecation warnings when upgrading.
> >
> > Yes. We disagree. My main point of contention here is that there needs to be a minimum amount of time for users to react to changes.
> >
> > You feel that 6 weeks is acceptable, such as in the case of 3.3 to 4.0.
> >
> > I feel that 6 weeks is far too short and have been arguing for 6 months.
> >
> >> Second, we
> >> disagree whether users should experience breaking changes when upgrading
> >> from 3.x to 4.x.
> >
> > I’m not so sure we disagree here. Because users are upgrading across a major release boundary there could be breaking changes.
> >
> > But breaking changes should only be in 4.0 and *not* in 4.1, 4.2, or 4.3.
> >
> >> We agree that users can experience breakages from 2.x
> >> to 4.x, with some intermediate deprecations.
> >
> > Yes. We agree (with my same caveat about breaking changes above).
> >
> >> Lastly we disagree on
> >> whether master can introduce breaking changes at any point, or only
> >> after some branching a major release from master.
> >
> > Yes. We disagree. This goes back to my main point of contention.
> >
> > Again, to me it really seems like the BlobStore is your main concern for being able to break things more quickly in order to rapidly improve the existing code. The ComputeService and other APIs don’t seem to be in such a state in general.
> >
> > What if you could work on the BlobStore and deprecate at any point between 2.0 and 3.0?
> >
> > If the BlobStore API had stabilized by 3.0 then perhaps it could move to the more conservative deprecation proposal. Thoughts?
> >
> > Regards,
> > Everett
> >
> >
--
Andrew Gaul
http://gaul.org/