Anakia
  1. Anakia
  2. ANAKIA-1

Remove Anakia and Texen from Engine distribution

    Details

    • Type: Task Task
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 1.6
    • Component/s: None
    • Labels:
      None

      Description

      I'd like to see us create separate builds and release cycles for Texen and Anakia now that we are TLP.

      ((I thought an issue already existed for this, but couldn't find it)

      In particular, Texen seems to have a minimal user base at this point. Be nice to have a separate release that is stable and mature, take it out of the Velocity upgrade cycle. If the user community gets excited about it again in the future, it'll be easy to add features and issue a new release.

        Activity

        Hide
        Henning Schmiedehausen added a comment -

        hmm, that one should have stayed at velocity.

        Show
        Henning Schmiedehausen added a comment - hmm, that one should have stayed at velocity.
        Hide
        Will Glass-Husain added a comment -

        I like your plan – seems a good way of balancing compatibility such a spin-off.

        No need to screw anyone over. A separate release cycle would probably be good for such dependent projects. If a Torque user has a patch they can create it without having to get involved with the full Velocity .

        Show
        Will Glass-Husain added a comment - I like your plan – seems a good way of balancing compatibility such a spin-off. No need to screw anyone over. A separate release cycle would probably be good for such dependent projects. If a Torque user has a patch they can create it without having to get involved with the full Velocity .
        Hide
        Nathan Bubna added a comment -

        All that you suggest is how i planned/hoped/wanted to do this from the get-go, with the one exception that i wonder if we really want to remove them in 1.7. If 1.7 is far removed from 1.6, then i think this is fine, but if it follows close on 1.6's heels (e.g. less than 6 months later), then i think it would be kinder to wait until 1.8 to remove them.

        Of course, we can worry about that when we get there.

        Show
        Nathan Bubna added a comment - All that you suggest is how i planned/hoped/wanted to do this from the get-go, with the one exception that i wonder if we really want to remove them in 1.7. If 1.7 is far removed from 1.6, then i think this is fine, but if it follows close on 1.6's heels (e.g. less than 6 months later), then i think it would be kinder to wait until 1.8 to remove them. Of course, we can worry about that when we get there.
        Hide
        Henning Schmiedehausen added a comment -

        You might want to reconsider this, given the fact that e.g. Torque is a heavy Texen user (actually I think that Texen was specifically invented to be the base of the O/R layer in Turbine that later became Torque). Torque has a big user base and screwing them over would be a Bad Thing (TM).

        I thought about this for a while and I would suggest the following:

        • Deprecate all the Texen and Anakia related classes from the main velocity tree.
        • Factor this code out into org.apache.texen and org.apache.anakia (the package change is intentional to allow them to be used in parallel with all Velocity Releases)
        • Release these tools immediately (without any further code changes) as anakia-1.0 and texen-1.0. Make it clear to all depending sub-projects that they must move to these releases ASAP.
        • Keep the deprecated classes around for any 1.5.x relase and 1.6
        • Remove them in 1.7 and 2.0
        • Keep developing Texen and Anakia on their own trees and release early, release often.
        Show
        Henning Schmiedehausen added a comment - You might want to reconsider this, given the fact that e.g. Torque is a heavy Texen user (actually I think that Texen was specifically invented to be the base of the O/R layer in Turbine that later became Torque). Torque has a big user base and screwing them over would be a Bad Thing (TM). I thought about this for a while and I would suggest the following: Deprecate all the Texen and Anakia related classes from the main velocity tree. Factor this code out into org.apache.texen and org.apache.anakia (the package change is intentional to allow them to be used in parallel with all Velocity Releases) Release these tools immediately (without any further code changes) as anakia-1.0 and texen-1.0. Make it clear to all depending sub-projects that they must move to these releases ASAP. Keep the deprecated classes around for any 1.5.x relase and 1.6 Remove them in 1.7 and 2.0 Keep developing Texen and Anakia on their own trees and release early, release often.

          People

          • Assignee:
            Unassigned
            Reporter:
            Will Glass-Husain
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development