On Apr 13, 7:38 pm, Daniel Lee <[email protected]> wrote: > Thanks for the comment Andrew. > > Version 2.x is meant to represent the experimental branch which will > be updated often. I wouldn't recommend anyone building live full- > production apps to rely on 2.x since it is the farthest thing from > being stable. In these cases, v=2 would be ideal which changes much > less frequently.
Yes I realise that (although there are those who don't apparently). But the point is that even those who ignore the advice [perhaps because they really want some feature which hasn't made it into v=2] should have some warning that their map might break. > If there's an alternative approach to how releases should be pushed, > documented, and announced, I'm more than open to hearing new ideas if > you have them. Ultimately, I'd like to establish and fine-tune a > process which works well for everyone. How about this: v=2.x is a beta-test by developers. If developers want to rely on a beta version for a production site, that's up to them; but people should still be notified in advance of a new beta release. Before a beta release is made, the release should be alpha-tested in- house. At a minimum, that should include making sure that every property of every object and every method of every class does what it should. And the code should not make it into beta until that alpha- test has been passed and signed off as such. It would be possible to flag an upcoming release when that testing starts: "Version 2.345 is being made ready for release as 2.x and will arrive in the next few days"; but what is absolutely crucial is the release notice itself: "Version 2.x is now 2.345". Now, there may be occasions when the release process itself goes wrong, so alpha-testing is passed but what is retrieved as v=2.x isn't being served correctly. That happens; but that means that the released version *also* needs to be tested as soon as it's released. All of this also applies to v=2. Making concrete announcements as a sticky thread in the Group would also allow developers a place to report problems of the type encountered with the latest 2.x release, which hopefully would get noticed more quickly than bug reports in the issue tracker. [I won't start on that] The Google Maps API is no longer a toy! This Group has over 40,000 members, and even beta versions *need* a proper release strategy. Saying "By the way, we changed things. Did anything go wrong?" after the event -- and especially when the Group was incandescent with trouble reports -- no longer cuts it. At the very very least, documentation for any new release of the API has to *accompany* the code. I'm sorry if this seems particularly vehement. All I know is what I have to do in the day job to get a software change authorised and implemented -- even into a pre-production environment. And I've been banging on about it here periodically over the last three years, with no effect :-( -- You received this message because you are subscribed to the Google Groups "Google Maps API" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-maps-api?hl=en.
