One thought is that we could do a few things that help with a 2.0 transition but does not require major API or file renaming changes. But maybe this creates more trouble than its worth:
a) Create a new serializer resource naming approach that does not use file extensions and they are automatically appended when the user specifies a string for a resource location. Maintain backwards compatibility but going forward, no file extensions are required or encouraged. Kindof like a scripting language where you don't have to specify the script file extension--its assumed. b) Encourage the use of a serializer interface (to be created). A specific instance of the serializer is then created. The old serializer just inherits from the new one for awhile until it is deprecated and removed as you mentioned. This separates usage from instantiation logic. Then a static factory method can be encouraged to create the serializer versus instantiated directly with the class. With this, you can change things whenever you want but still allow other ways to create serializers. Or create a Configuration object which creates the serializer and makes this the new way to instantiate a serializer (a bit heavyweight for pivot though). c) Not sure about other nooks, such as the wtkx:id, however, I think XML has a xsi:schema type mapping that creates aliases. I know this is how spring maps schemas to different versions for validating xml files but keeps the same namespace declarations consistent across versions. d) Could just have your build script copy the annotations to the new name for awhile even before 2.0 for those that are writing new code. You have to write a converter anyway so you could use it in the build to start with. I agree though that there are a lot of little nooks to ensure is backwards compatible and it so *any* type of soft transition could be brittle and confusing. Most likely, even a script is not foolproof. I think that major changes to existing API needs to be on a major release cycle, although I am not a stickler for it. There are some are some API *enhancing* changes that can make it easier once 2.0 hits and perhaps this should be the target now. -----Original Message----- From: Greg Brown [mailto:[email protected]] Sent: Tuesday, June 15, 2010 8:12 AM To: [email protected] Subject: Re: Pivot 1.6->2.0 That's the problem - we can't easily support backwards compatibility. I had originally hoped to have WTKXSerializer extend BeanSerializer in Pivot 1.6, and then drop WTKXSerializer in 2.0. However, we can't do that with @WTKX/@BXML, because annotations can't inherit. So, we're kind of stuck with an all-or-nothing approach, unless we introduce a cross-project dependency such that BeanSerializer also looks for WTKX annotations, which I really don't want to do. That is why I am suggesting that we go to version 2.0. I was thinking that we could provide a script that will do a search/replace/rename so developers don't need to do this manually. That should at least make the transition a little easier. On Jun 15, 2010, at 3:53 AM, Noel Grandin wrote: > > Sure, but surely we can provide aliases for those things internally so > existing files continue to work? > Maybe with a runtime warning to System.out so people know that they need > to upgrade at some point. > > It just seems a little harsh to dump that amount of work on people when > we can reasonably easily provide a gradual upgrade path. > > -- Noel > > Greg Brown wrote: >> Files with a .wtkx extension will still work fine. However, the "wtkx" namespace prefix will change to "bxml", the annotation will change to @BXML, and the serializer will change to BeanSerializer, so for consistency I think we'd want to recommend changing the file extension as well. >> Greg >> >> >> On Jun 14, 2010, at 4:52 PM, Noel Grandin wrote: >> >> >>> Hi >>> >>> I don't have a problem with the version numbering, but is there any >>> reason why you can't continue to support the WTKX extension for >>> backwards compatibility? >>> >>> -- Noel >>> >>> On Mon, Jun 14, 2010 at 02:13, Greg Brown <[email protected]> wrote: >>> >>>> Hi all, >>>> >>>> I'd really like to refactor WTKXSerializer to BeanSerializer and move it to Pivot Core for the next release. However, I think this change is too disruptive for the 1.x line. As a developer, I don't think I would be too pleased to discover that I need to update all of my WTKX files to BXML when migrating from Pivot 1.5 to Pivot 1.6. As a result, I'd like to suggest that the next major version of Pivot be 2.0. >>>> >>>> We currently have Pivot 1.5.1 in the pipeline and can do additional point releases for 1.5 as needed. We'll reshuffle the items currently assigned to 1.6 and 2.0 into 2.0, 2.1, etc. as appropriate. Any objections? >>>> >>>> Thanks, >>>> Greg >>>> >>>> >>>> >> >
