Hi to all Developers,
I have been following this thread for some time now. Being a Person
that is only watching, I came to the conclusion that You as Developers
have a totally different understanding as of what should be a 2.4
Release.
Right now you are quarreling about things that should be defined once
and then be clear to everyone. Looking at the Message History,
quarreling and endless discussions are quite common to this project.
I know I am an outsider talking, but my Company is spending a certain
amount of time and money into this project by giving Norman the
opportunity to support this project (the official way). We chose james
because we felt that James has a good codebase, and gives us the
opportunity to extend its functionality to what we need. We have a lot
of Experience in E-Mail Clusters and E-Mail Product Solutions. Nothing
was as easily extendable as james. On the Contrary, the Feature Set is
still very limited.
That said, there have been great efforts in widening this topic. Our
Companies Goal is to make the JAMES Server a State-Of-The Art E-Mail
Server which can be used as a drop-in solution with best-of-breed
solutions to common problems.
What we have found out is, that this project is willing to walk the
way with us. BUT I have also found out, that the Members are hindering
themselves to some extent by not talking objectively about certain
topics.
I see and understand that there are different understandings about
release planning. So I want to first lay the cornerstone for the next
release. Please vote on which mechanism you want to keep on
developing. Vincenzo suggested the most common approach
project-x.y.z releases where
x - is a release change that is not backwards compatible, or contains
major feature enhancements, that involve more inspection by the
user, because current configurations are incompatible with this
release.
y - is a release change that is backward compatible, but contains
major feature enhancements. The Installation is not guaranteed to
be working with current configurations, but most likely will.
z - is completely compatible to the previous release, and contains
only bugfixes.
From what I understood from the recent posts, is that release planning
was handles different in the past, and why should one change it now,
when it was different in the past. Well IMHO we all evolve with a
project. Sometimes certain decisions are good, sometimes they are bad.
But just because there have been bad decisions does not mean to keep
bearing with them instead of changing them to something better.
But the version numbering is only solving half the problem. The next
thing is to define what should be inside a Release. this should first
be analyzed by topic i.e. will feature a be an incompatible change, or
not.
Successful Open-Source Projects (Eclipse, ...) have a strict Release
Plan (Minor Releases every 6 Months, Major Releases every Year), with a
certain set of features. The Feature Sets should be chosen, so that the release
is
possible. The Projected Release Dates are fixed to some
extend. If a Release Date is coming closer, and it is obvious that a
certain feature can not be implemented/integrated to the projected
date, there should be a vote on what to do. Move the Release Date, or
Move the Feature to the next Release Cycle.
Those Rules should be clear to everyone, so noone has to argue or
quarrel about what is a next release.
That said/written please vote about how release planning should be
considered in the future.
I would consider the discussed road map to be the 3.0 road map,
Norman and Stefano should be responsible for its development. Features
that are wanted in 2.4 should be backported by the people that want
it within 2.4 release. Noel and Vincenzo should be responsible fpr the
2.4 release. If there are Problems during backporting/migration of
features Stefano and Norman should be available for helping, but
should keep their focus on 3.0
So please step back from terms of throwing trunk on people and the
like, and keep focus on the project. Clear the misunderstandings out,
vote on release planning/cycles terminology. Keep focus on the
project in favor of interpersonal dislikings.
Again I know I am an Outsider, but still I hope you consider my
suggestions to this project
Kind regards
Juergen Hoffmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
