Talk:Road Map

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

GPL and Apache License compatibility is discussed here:

There has been doubts about this roadmap been exemplary for ADempere. The latest comment came in thisSF thread by clamerio. Prior to this Colin Rooney and Mike Judd has also raised that the Roadmap has to be reflective of subject matter and features. Ever since there are been attempts to eyeball this. We appreciate anyone to keep on constantly improving on it. Thank you to those who has done the roadmap so far - Red1 01:04, 14 April 2007 (EDT)

Red1, I think that defining the roadmap is not a wiki-edit effort. It must be a community effort, some decisions through polls, like clameiro proposed, other decisions based on sponsored work, other decisions based on time-contributions possibilities of developers, others decisions taken by council, etc. It's also very important what we discussed on this CC meeting that I'm bringing here for discussion (CarlosRuiz 12:14, 14 April 2007 (EDT)):

It was agreed that current roadmap is confusing and must be discussed in a later stage with more people from council and community.

  • Roadmap must not match with any specific technology or brand or name, only in very special cases
  • Roadmap must not have version numbers for things that are not firm yet, probably just some direction for possible future enhancement for those stuff
  • Roadmap should convey a clear message to the community - what is committed ( i.e confirm ), what is under investigation ( experiment welcome ) and what is don't know when ( volunteer welcome )
Thanks Carlos Ruiz for anchoring here, where ppl keep refering to when they search for it. - Red1 21:02, 14 April 2007 (EDT)

At 2nd European ADempiere Conference, a Road Map task force was establish (Victor, Mario, Carlos and Jörg). Primarily as a proposal to these people: Can we put onto this page the following table and refer to it from the starting page:

Release Date from Content
3.6.0 RC 1 30.06.09 trunk
  • Experimental OSGi Container [joerg.viola]
  • FIrst fitnesse test added [carlos]
  • 50 P9 Bugs left [all]
3.6.0 RC 2 30.07.09 trunk
  • OSGi Container stabilized [joerg.viola]
  • Experimental Libero plugin [vcp-jp]
  • Experimental Windows installer [kai]
  • Simple Sales and Purchase fitnesse Test added [mjudd]
  • Improved documentation I [red1]
  • 30 P9 Bugs left [all]
3.6.0 RC 3 30.08.09 branch_3_6
  • Base Language [nwessel]
  • Stabilized Libero plugin [vcp-jp]
  • Stabilized Windows installer [kai]
  • Basic Fitnesse Suite stabilized [mjudd]
  • Improved documentation II [red1]
  • 20 P9 Bugs left [all]
3.6.0 Frenzy 30.09.09 branch_3_6
  • OSGi Container stable [joerg.viola]
  • Libero plugin stable [vcp-jp]
  • Windows installer stable [kai]
  • Base Language stable [nwessel]
3.6.x ? branch_3_6
  • Bugfix releases
3.7.0 RC 1 30.10.09 trunk
  • Experimental P2 Installer
  • Experimental PluginCockpit (in Installer?)
  • Experimental Pentaho adapter
  • Account tests [mjudd]
3.7.0 RC 2 30.11.09 trunk
3.7.0 30.12.09 branch_3_7
3.7.X branch_3_7 Bugfix releases

As you can see, this roadmap would include:

  • release candidates once a month from trunk
  • a one month stabilization phase in branch
  • a stable release every 3 months
  • a defined set of "features" per release
  • a responible "maintainer" per feature
  • if a features misses a release, it is postponed to the next one
  • even "experimental" feature states must not break production-ready state of a release

What do you think? viola 08:48, 22 June 2009 (PDT)

Year End Closing Functionality

This is desired. Someone implemented it here: