A deprecation phase could be used, but I don't think it's worth it.
Is it so a big deal for anyone? (this is a request for explanations, if any,
not just a yes ...)
Jacques
From: "BJ Freeman" <bjf...@free-man.net>
+1
=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
Jacopo Cappellato sent the following on 4/23/2010 12:58 AM:
On Apr 23, 2010, at 8:24 AM, Adam Heath wrote:
Jacques Le Roux wrote:
From: "james_sg" <snowme...@hotmail.com>
+1
For 2), may I suggest that the new run-install should print out a list of
run-install-* variants and their explanations?
There is already the traditionnal ant -p for all targets, but yes, why
not...
Sorry, that brings us back to the start of this. Changing what
run-install does is what I thought we decided against.
I don't think we decided this.
It can print
suggestions/warnings, but it should still process whatever cmdline
args just like it always has.
I think it is better to simply inform the user that there are now new commands (e.g. load-seed-data and load-demo-data) and stop;
this solution addresses all the concerns about confusing users and it represents a good way to inform the old users (that don't
read the README and release documentation) about the new commands.
Jacopo
