Current names of Style and Layer hooks:
* hook_openlayers_layers_info().
* hook_openlayers_styles_info().

I think we should drop the _info part as it is unnecessary and just confusing. In 1.x it made some sense because the idea was to actually just provide enough enough and a callback in the hook, but this is no longer true.

Comments

tmcw’s picture

tmcw commented

There are implementors for these hooks; we should either maintain backwards compatibility or make sure everything is upgraded before changing these.

zzolo’s picture

zzolo commented

Well, I was never under the impression that we were going for backwards compatibility (though there is no reason to change things arbitrarily). I think we can manage coordinating with the existing modules/packages that use these hooks, and as it still says alpha, I think this is a positive change to the API that we have a chance to make now.

tmcw’s picture

tmcw commented

Uh, I'm fine with breaking backwards compatibility with other branches and also fine with changing the API, but there's the possibility here of breaking a lot (read all) sites if this isn't coordinated. Pointing to the alpha tag as permission to make extreme changes is ignoring the fact that 2.x is the second most used branch (after 0.x). It may be alpha, but that doesn't quite mean that it's a sandbox right now.

zzolo’s picture

zzolo commented

I have no desire to screw over the users of Managing News or to thwart the development direction of Managing News, but the number of users does not negate a good development cycle for this module. Nor should the Managing News roadmap solely dictate how this module should be developed.

Alpha releases, generally, are not guaranteed or supported in anyway, as key features and API are still subject to change. In fact, most software development cycles don't even involve making an alpha release "publicly" available at all. That still doesn't mean I have intentions of making wild changes without telling anyone.

Creating a detailed roadmap for the 2.x branch, as I have suggested, would create a framework where we can manage our own expectations and the expectations of our users, and this conversation wouldn't even be needed. I strongly suggest that we work at this, so that these conversations don't continue to take away form real work.

tmcw’s picture

tmcw commented

I don't have any problem if you're fine with coordinating this change. The technical definition of 'alpha' is completely irrelevant, and a roadmap isn't related to this problem - my opinion is that we can and should keep the 2.x branch stable from day to day.

zzolo’s picture

zzolo commented
Assigned: Unassigned » zzolo

Obviously most of this thread has not even touched on the actual question I posed. And your opinion on keeping things "stable" is just as relevant to this specific issue as my desire to have a roadmap.

But continuing onwards off topic: the "technical" definition is not important or necessarily applicable, but a/our definition of alpha is very relevant because we have put it as a label to this module, and there are expectations that come with that label. And, as we have not defined that ourselves, the best thing anyone, including me, can assume is a "technical" definition. The same goes with saying something is "stable". So, if the technical definition is irrelevant, then lets find our own definition so that these silly arguments don't need to happen.

I personally don't agree that we need to maintain stability from day to day, and from some of phayes' comments, I think he feels similarly (assumingly). But instead of just wildly making the changes I would like to see, I would rather discuss what our expectations are for this going forward for the development process and for our users. I can easily commit this change, but its a rather significant change in the API, so I thought getting an opinion on it would be a good first step.

Back to issue at hand: Going forward (giving some time for phayes to jump in if desired):

* Commit change
* Update 2.x documentation
* Update upgrade documentation (from 1.x)
* Ensure that in release notes for next alpha and onwards, this is noted.

tmcw’s picture

tmcw commented

Okay, I'd like to fix the current bugs in 2.x-dev and 2.x-alpha2 and then tag an alpha3 release so that sites can get the many bugfixes of the last week and a half without breaking compatibility. Then put up a big warning about updating to alpha4, after this change is made. Does that work for you?

zzolo’s picture

zzolo commented

Sounds good to me.

zzolo’s picture

zzolo commented
Status: Active » Fixed

http://drupal.org/cvs?commit=338204

* Updated in code.
* Updated documentation on drupal.org
* Need to include on release notes
* Maybe some more obvious way of noting change. Putting on the project page is probably not appropriate because we have not done this with any other changes.
* @tmcw, I'll assume you will notify ManagingNews, Mapbox, Geolocator, Geo_Taxonomy
* I notified openlayers_geocoder: #735386: Change in OPenLayers hook names

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.