markus schnalke wrote:
It seems to me as if you would be doing compatibility for
compatibility's sake. This is sticking to old cruft. Caring to much
for some old userbase likely keep you from getting new users while old
ones slowly vanish. This also includes frontends. It is a dead end.
I value clearer and simpler solutions above compatibility in any case.
I understand the importance for compatibility in case of a backend,
but it should never be for it's own sake, but this is what I feel here
again and again.
Is nmh just good enough for you and therefore better not changed? Is
updating your setups once a year more effort than the improvements of
modernization? It could be and I would understand.
I think compatibility is critical for any "mature" software project.
Breaking it should always be a really big deal, only done if there
is absolutely no way around it, and announced clearly in upgrades.
(Even then it's hard to be sure users will notice -- consider the
case of individual users on a multiuser system who get a new nmh
version as a result of the sysadmin doing a distribution upgrade.
The sysadmin might see release notes (but likely not), the users
certainly won't.)
This isn't particularly nmh specific. Any time you break back compat
it annoys all your existing users.
Basically, if your project is still new, under development and in
some sort of 0.xx version you can get away with breaking compatibility
in pursuit of code cleanup. As the project ages the tradeoffs change.
I do want to see nmh improved, but if compatibility is broken
this needs to be for a really good reason, and the "new" setup
must be fully thought out so it doesn't have to change again,
and well documented and changes loudly advertised in changelog
and release notes.
I don't see any reason why we can't make nmh better than it is:
the principle barrier has IMHO been that there haven't been enough
people who have had the time/effort/inclination to actually write
the code to improve things. (I also think that this is a more
sensible approach than the "throw away and rewrite" idea and
I'd prefer it if we didn't use "nmh2" as a name for the latter.)
-- PMM
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers