Benjamin Zeiss wrote:

Hi,

...

after releasing TRex 0.5.3, we intended to head directly for TRex 0.6.0, unless there are no critical bugs which require a 0.5.4 release.

Now, I just realised that two feature requests are explicitely scheduled in JIRA for 0.5.4 by Benjamin. I have no problems with this, but I just like to document via this email that we aim at 0.5.4.

Benjamin, is that what you intend?

If yes, I will re-schedule the already fixed bugs (in particular TTC-222) from 0.6.0 to 0.5.4.

Hm...well i wasn't thinking too much when i moved these issues to 0.54. I just wanted to state that these are needed with a higher priority and with 52 unresolved bugs or so for 0.60 they would certainly not stand out. In fact, we should think about the release schedule and how we schedule them in the future, because we won't _ever_ reach 0.60 if we keep scheduling all new bugs for the 0.60 version. I suggest we in fact make a 0.54 release and maybe move something like 10 additional outstanding non-major issues from 0.60 to 0.54 and then move some 0.60 features to later 0.60 versions. I think we should aim at something like 30 issues per release.

You are definitely right: currently, too much bugs are scheduled for 0.6.0.

While I have already started to move some issues from 0.6.0 to 0.5.4, I am just asking myself, whether we should not move all current 0.6.0 issues to at least 0.6.1 and move the current 0.5.4 issues back to 0.6.0. -- Simply for the reason that the issues which we consider currently the highest priority are mainly not bug fixes for the 0.5.x series but new functionality which is better characterised by a 0.6 version number.

Opinions?

Helmut

Benjamin Zeiss wrote:

We should create a rough road map. The outstanding major features that we intend to get in mid-term that i can think of right now:

• compiler integration (this includes some kind of standard way for a

compiler integration, i.e. the telelogic integration probably has to be rewritten as well. we should also investigate the openttcn integration - think they have also a compiler now rather than an interpreter - at least the openttcn guy contacted me some days ago stating that i would require visual c++ for the new version)

• metric analysis
• semantic analysis
• pattern analysis

features necessary for stability and peformance to make it actually widely usable:

• parser optimization
• incremental parser
• dependency analysis (i.e. analyze only dependant files)

maybe we should aim to have this package in the 1.0 release?

here is an idea:

0.60

• compiler integration (tau, danet. openttcn TBD)

0.70

• metric analysis
• semantic analysis

(two major features since metric analysis is basically done and only parts need to be rewritten)

0.80

• pattern analysis

0.90

• parser optimization
• incremental parser
• dependency analysis (i.e. analyze only dependant files)

1.0

• stabilizing everything from 0.90.

depending on how the pattern analysis progresses, we could swap the 0.80 and 0.90 contents. Given such a roadmap, we could indeed skip the 0.54 release and make it 0.60. All the little issues should then be spread across those versions and the 0.01 increments depending on their importance. What do you think about that?

Sounds reasonable (except that I would add "implement further refactorings" somewhere, e.g. around 0.8 and 0.9.).

If you like, I may create new release versions in JIRA, attach your feature description to each version description, and distribute the existing issues to them.

Bye, Helmut

Benjamin Zeiss wrote:

...

If you like, I may create new release versions in JIRA, attach your feature description to each version description, and distribute the existing issues to them.

As everyone who has got a bunch of JIRA notification emails has realised, I have just rescheduled all issues. (I have not added a 0.6.2, yet. I intend to do this once 0.6.0 has been released and a refinement of the 0.6.1 is due.)

Bye, Helmut