[#MULE-891] Plan roadmap to 2.0 via 1.3.x, 1.4.x

Mule

Plan roadmap to 2.0 via 1.3.x, 1.4.x

Created: 27/Jun/06 12:42 PM Updated: 04/Oct/06 06:15 AM

Component/s:

Tools

Affects Version/s:

None

Fix Version/s:

1.3.1

Time Tracking:

Not Specified

Issue Links:

Related

This issue relates to:

~~MULE-893~~ Clarify/reachitect MuleMessage property mutability & handling

~~MULE-897~~ Review the entire code base (or at minimum the classes used by multiple threads) for correct memory synchronization

~~MULE-639~~ Investigate JDK 1.5 as base platform for upcoming Mule versions

MULE-947 Unify access to shared variables by using proper accessor methods

MULE-710 Queues could be implemented via java.util.Queue

MULE-774 Overhaul QueuePersistenceStrategies

MULE-967 Create and enforce simple, yet correct UMOMessage synchronization rules

MULE-863 Clean up exception handling to not "log & throw"

~~MULE-966~~ Improve receiver/dispatcher state handling for better thread safety

~~MULE-892~~ Clarify Endpoint/EndpointURI mutability

~~MULE-732~~ FutureMessageResult.execute() creates new threads

This issue relates to:

~~MULE-894~~ Define feature set for 2.0, 2.x

Labels:

Description

« Hide

We need to come up with a roadmap (and I mean the kind we stick to

in order to not get tangled up with 2.0 aka "the holy grail release". That should probably start immediately after the final release of 1.3. Obvious ly there can be a 1.3.x series for bug fixes, but I also propose a 1.4 stepping stone since there are important (IMHO blocking) things that must be clarified before we even think of adding more features like distribution, failover etc. I'll outline issues separately with fix-version 1.4 and link to this one.

All

Comments

Work Log

Change History

Transitions

FishEye

Sort Order:

[ Permlink | « Hide ]

Andrew Perepelytsya added a comment - 27/Jun/06 12:55 PM

Holger, we (you) could identify those issues and set their fix version to 1.4. We will try to ensure there's no scope creep. Let it be even 2-3 issues, but the ones to be focused on.

At the same time the 2.x development can be started (granted, the 1.4 has moved to the branch). Immediately after the branch is created, I'll set up the merge tracking via svnmerge, so that 1.4 fixes can be merged regularly into the latest code without any conflicts.

Questions:

1. Do you have the permission to create a 1.4 release version in JIRA? Just ping the list if you don't.
2. The branch will be created after 1.3 final, so I think we won't miss that moment to perform any required merging post-setup

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 27/Jun/06 01:24 PM

Btw, some background - the linked issues came up after a longer discussion with Ross after I found another (very rare, but disturbing since untraceable) concurrency bug. We absolutely must get them right for stability reasons, otherwise "strange" bugs will just creep up in odd places, or - even worse - without being noticed, silently corrupting data.

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 27/Jun/06 01:38 PM

assigning to me. thanks for volunteering >

[ Permlink | « Hide ]

Lajos Moczar added a comment - 04/Oct/06 06:15 AM

This has been done in my Mule Project Plan which we have discussed and will finalize on the 09 Oct meeting.