On Thu, Aug 22, 2013 at 2:04 PM, Martijn Dashorst <[email protected]> wrote: > > On Thu, Aug 22, 2013 at 10:09 PM, Ben Tilford <[email protected]> wrote: > > > There really isn't a good reason to remove them even if parameter injection > > is added. > > > Yes there is: > - removing maintenance burden > - removing confusion > - making the implementation of the new API feasible. > > Removing maintenance burden > > Instead of just having to maintain the new API, we have to maintain the old > API in the same codebase, and ensure compatibility remains between the two. > This may be harder than it seems from the outset.
the pageparameter api hasnt really been a source of bugs or a maintenance headache. internally we will still need a datastructure to carry the parameters, might as well reuse whats there now. further, what will the api look like to generate bookmarkable urls? still need pageparameters to carry those params forward in bookmarkablelink, etc. > Removing confusion > > Keeping both APIs means there exist multiple ways to achieve the same thing > which is bad: what would happen if you use both PageParameters and the new > API in the same class or constructor? i dont by this, same can be said for constructor vs field injection. what if they define some params in constructor and others in fields? -igor > Making implementing the new API feasible > > The previous point brings us to the need to specify that behavior. The time > to cleanly specify that behavior cannot go into making the new API the best > way it can. I'd rather spend my time making the new API as clean and > practical as possible, than to invest in making an deprecated API work > together with the new API. > > > > If they have to be removed at least deprecate and remove in v 8. > > > > We promised to use semantic versioning with our releases, and that brings > API compatibility between minor releases. We have kept that promise. In > return we are allowed to break API in major versions. According to semantic > versioning we have to deprecate the affected APIs in a minor release prior > to releasing the new major version: > > From the semver.org FAQ: > > > How should I handle deprecating functionality? > > > > Deprecating existing functionality is a normal part of software > > development and is often required to make forward progress. When > > you deprecate part of your public API, you should do two things: > > (1) update your documentation to let users know about the change, > > (2) issue a new minor release with the deprecation in place. Before > > you completely remove the functionality in a new major release > > there should be at least one minor release that contains the > > deprecation so that users can smoothly transition to the new API. > > But please don't focus on the API that gets removed, instead help us define > the new API. > > Martijn
