My concern for backwards compatibility is really to provide a clean upgrade
path to my users. So for me it is mostly maintaining some form of backwards
compatibility for a few months until all the users have upgraded. This is
because we have multiple clusters and having users maintain two versions of
their code so they can run on multiple clusters is something they would
complain a lot about. I know that for other groups it will likely be similar,
but their time-frame and the versions they will be going from/to will be
different. In general I am in favor of maintaining API, wire, and binary
compatibility as long as is easily possible, and if we cannot it needs to be a
conscious decision that involves changing the major version number of storm.
Changing the package names is very much a non-backwards compatible change. But
in this case the backwards compatibility I put in is a real hack. That is why
I put it in a jar named storm-rename-hack in a java package named
org.apache.storm.hack. Additionally it is off by default, and when it is on,
and it does anything to the jar it warns you repeatedly that you need to
upgrade your namespaces. I personally think that this is a one off situation.
We are not going to break compatibility that often, because we have the tools
we need to maintain compatibility, and we have been using them fairly well
lately. Now that being said compatibility is theoretical until someone
actually tests it. Small bugs can always creep in so if you do want to go from
one version to another you need to be sure that you have tested it, like any
other software.
- Bobby
On Tuesday, November 17, 2015 5:57 PM, Hugo Da Cruz Louro
<hlo...@hortonworks.com> wrote:
+1 as well. I support moving to the org.apache.storm package as early as
possible and I am OK with storm-compat. My only concern with using storm-compat
is if we are going to have to support it forever, or plan on dropping it after
a certain release. Backwards compatibility is a valid concern but it can become
very difficult to maintain older versions and at some point we must say that
only topologies built after version X will run for version Y onwards (Y > X)
Hugo
> On Nov 16, 2015, at 5:23 PM, Harsha <st...@harsha.io> wrote:
>
> +1 on Bobby's suggestion on moving the packages to storm-compat and have
> it part of lib folder.
> Moving 1.0 with org.apache.storm will make it easier in the future
> rather than wait for 2.0 release we should make
> this change now and in 2.0 we can remove the storm-compat jar.
>
> Thanks,
> Harsha
>
>
> On Thu, Nov 12, 2015, at 07:15 AM, Bobby Evans wrote:
>> I agree that having the old package names for a 1.0 release is a little
>> odd, but I also am nervous about breaking backwards compatibility for our
>> customers in a very significant way. The upgrade for us from 0.9.x to
>> 0.10.x has gone fairly smoothly. Most customers read the announcement
>> and recompiled their code against 0.10, but followed our instructions so
>> that their topologies could run on both 0.9.x and 0.10.x. Having the
>> ability for a topology to run on both an old cluster and a new cluster is
>> very important for us, because of failover. If we want to minimize
>> downtime we need to have the ability to fail a topology over from one
>> cluster to another, usually running on the other side of the
>> country/world. For stability reasons we do not want to upgrade both
>> clusters at once, so we need to have confidence that a topology can run
>> on both clusters. Maintaining two versions of a topology is a huge pain
>> as well.
>> Perhaps what we can do for 1.0 is to move all of the packages to
>> org.apache.storm, but provide a storm-compat package that will still have
>> the old user facing APIs in it, that are actually (for the most part)
>> subclasses/interfaces of the org.apache versions. I am not sure this
>> will work perfectly, but I think I will give it a try.
>> - Bobby
>>
>>
>> On Thursday, November 12, 2015 9:04 AM, Aaron. Dossett
>> <aaron.doss...@target.com> wrote:
>>
>>
>> As a user/developer this sounds great. The only item that gives me
>> pause
>> is #2. Still seeing backtype.* package names would be unexpected (for
>> me)
>> for a 1.0 release. That small reservation aside, I am +1 (non-binding).
>>
>> On 11/11/15, 2:45 PM, "임정택" <kabh...@gmail.com> wrote:
>>
>>> +1
>>>
>>> Jungtaek Lim (HeartSaVioR)
>>>
>>> 2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <ptgo...@gmail.com>:
>>>
>>>> Changing subject in order to consolidate discussion of a 1.0 release in
>>>> one thread (there was some additional discussion in the thread regarding
>>>> the JStorm code merge).
>>>>
>>>> I just want to make sure I’m accurately capturing the sentiment of the
>>>> community with regard to a 1.0 release. Please correct me if my summary
>>>> seems off-base or jump in with an opinion.
>>>>
>>>> In summary:
>>>>
>>>> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
>>>> 2. We will NOT be migrating package names for this release (i.e.
>>>> “backtype.storm” —> “org.apache.storm”).
>>>> 3. Post 1.0 release we will go into feature freeze for core
>>>> functionality
>>>> to facilitate the JStorm merge.
>>>> 4. During the feature freeze only fixes for high priority bugs in core
>>>> functionality will be accepted (no new features).
>>>> 5. During the feature freeze, enhancements to “external” modules can be
>>>> accepted.
>>>> 6. We will stop using the “beta” flag in favor of purely numeric version
>>>> numbers. Stable vs. non-stable (development) releases can be indicated
>>>> on
>>>> the download page.
>>>>
>>>> Do we all agree?
>>>>
>>>> -Taylor
>>>>
>>>>> On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <ptgo...@gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>> On Nov 11, 2015, at 9:28 AM, Bobby Evans
>>>> <ev...@yahoo-inc.com.INVALID>
>>>> wrote:
>>>>>>
>>>>>> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
>>>> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
>>>> list.
>>>>>>
>>>>>> Some of them are more important then others but they are all things I
>>>> would like to see in a 0.11.0 release.
>>>>>
>>>>>
>>>>> Cool. Thanks for listing them out. I will add them so they get
>>>> tracked.
>>>>>
>>>>>
>>>>>> On a side note I don't think the beta releases have been helpful. I
>>>> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
>>>> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
>>>> but
>>>> it is not that big of a deal for me.
>>>>>
>>>>> In my mind, having releases tagged as “beta” were a way for us to say
>>>> to
>>>> users “here’s a preview release that will allow you to kick the tires on
>>>> upcoming features, but be aware that there might be bugs. Let us know if
>>>> you find any so we can fix them.”
>>>>>
>>>>> I think the intent was sound, but what I didn’t really see was user
>>>> feedback on the beta releases, which is what I hoped would happen. So I
>>>> have no problem with dropping the use of “beta” flags.
>>>>>
>>>>> Another approach I’ve seen other Apache projects use is to the
>>>> numbering
>>>> scheme you describe, and just have different labels/descriptions on the
>>>> download page — i.e. “Latest stable release” and “Latest development
>>>> release.” The nice part of that convention is that it does not have any
>>>> impact on the release process. For example if we’re confident that a
>>>> particular “development” release is actually quite stable, all we would
>>>> have to do is update the downloads page, rather than go through the
>>>> whole
>>>> release/vote process just to remove the “beta” tag.
>>>>>
>>>>>> I also would like to see the 0.11 release tied to the plan for the
>>>> JStorm merger. If we don't tie them together there can be code that
>>>> does
>>>> not make it into 0.11, but could make it into a 0.12 that will
>>>> immediately
>>>> be caught up in the merger, that could take a long time to complete. I
>>>> mostly want us to be very transparent about what is likely to happen
>>>> after
>>>> 0.11 is released. So if someone has a feature that is close to getting
>>>> something in to 0.11 that they speak up here instead of just deciding to
>>>> wait for a 0.12 release.
>>>>>
>>>>>
>>>>> I agree that the 0.11 release needs to be tied to the JStorm merger.
>>>> Once that release goes out, we’ll be going into lockdown mode for the
>>>> merge
>>>> effort, which is likely to take a while.
>>>>>
>>>>> During that time it’s highly unlikely that any changes/additions to
>>>> Storm’s core functionality will be accepted beyond high-priority bug
>>>> fixes.
>>>> Adding new features to the “external” components during that time is
>>>> probably okay, since those components are sufficiently decoupled from
>>>> Storm’s core functionality.
>>>>>
>>>>> So to reiterate Bobby’s statement:
>>>>>
>>>>> Please speak up now if there are any specific features or changes to
>>>> Storm’s core functionality that you’d like to see in the next release.
>>>> Otherwise you will have to wait.
>>>>>
>>>>>> - Bobby
>>>>>
>>>>> -Taylor
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wednesday, November 11, 2015 6:32 AM, John Fang <
>>>> xiaojian....@alibaba-inc.com> wrote:
>>>>>>
>>>>>>
>>>>>> Totally agree， it's great to accelerate the release speed. it is
>>>> better release one official version within 3 months. The first month is
>>>> for
>>>> developing new features , .If some features hasn't been finished in this
>>>> month, it will be put in the next release ticket. In the last two
>>>> month, we
>>>> just do test.
>>>>>> Storm may face the greatest challenge in a big cluster, so I am more
>>>> concerned about ZK Optimization as jstorm did. At last, it's great for
>>>> the
>>>> next release to has a test report about the stability and performance ,
>>>> due
>>>> to lots of new features in the latest versions.
>>>>>>
>>>>>> Regards
>>>>>> John Fang
>>>>>>
>>>>>> -----邮件原件-----
>>>>>> 发件人: P. Taylor Goetz [mailto:ptgo...@gmail.com]
>>>>>> 发送时间: 2015年11月11日 6:16
>>>>>> 收件人: dev@storm.apache.org
>>>>>> 主题: [DISCUSS] Initial 0.11.0 Release
>>>>>>
>>>>>> I’d like to start discussing our next release (0.11.0).
>>>>>>
>>>>>> First off, I’d like to create a list of issues/features that are
>>>> in-progress and not yet merged to master, so we can start tracking them
>>>> for
>>>> inclusion in the release. If there are specific JIRAs you would like
>>>> included, please reply, and I will add them to the wiki page for the
>>>> 0.11.0
>>>> release [1].
>>>>>>
>>>>>> Second, I’d like to propose modifying the release cycle a bit. I’d
>>>> like
>>>> to continue the beta release cycle we started with 0.10.0, but this time
>>>> I’d like to consider adding some sort of temporal constraint so we
>>>> release
>>>> new betas more often — something like a new beta release every 3 weeks
>>>> or
>>>> so until we feel confident in dropping the beta tag. IMHO, there was too
>>>> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
>>>> interim releases during that time.
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>> -Taylor
>>>>>>
>>>>>> [1]
>>>>
>>>> https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
>>>> Set
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Name : 임 정택
>>> Blog : http://www.heartsavior.net / http://dev.heartsavior.net
>>> Twitter : http://twitter.com/heartsavior
>>> LinkedIn : http://www.linkedin.com/in/heartsavior
>>
>>
>>
>>
>
