Arbitrary development snapshots are provided in the download directory. A development snapshot documents the current state. It's not meant for production use. A development snapshot doesn't fix all bugs, but represents a step towards that goal.
CPAN contains milestones and releases of Carrot.
Your interest in bringing Carrot forward is welcome. You understood that it's a highly experimental piece of software and not ready-made entertainment from an appstore. You are willing to read straightforward Perl code and you are able to understand it as a whole.
You can either use the RT Bug tracker, which is a default feature any Perl module on CPAN has.
Or you use the bug tracker at Google Code.
Or you simply drop the author an e-mail. The address is win at carrot-programming.org.
Be warned that the mailing list carries patches (up to 10kb uncompressed) and attachments (up to 100kb compressed). It might be high volume at times. Only join if you know how to handle.
The mailing list is currently at Google Groups. It's name is carrot-programming. You need a Google account to join.
For Carrot there has been only one direction: fast forward. Code was thrown at a high rate, so that the idea to perfectly manage it wasn't seriously considered. The idea to branch-stage-merge a single known file convinces in SCM tutorials, but not during a conceptual development phase. Over 2.200 blind substitutions were performed on the whole source tree, dozens of more advanced re-formatting scripts were written, top-level directories changed several times. The main challenge was to get changes right practically, not formally. Forward means: with least work, not with perfection.
However... Carrot is heading for a level of maturity where more code is added than thrown. A level where you postpone work for a few days and still recognize everything once you resume. And at that boring level source code management will become mandatory for Carrot. Probably soon. Until then: enjoy life and use whichever tools you want as long as your submitted patches bring Carrot forward.
Contributions are welcome under the following conditions.
- Full name, full disclosure.
- Carrot is about expressiveness and so should be your contribution. Counter example: your agenda is about a blind-feature competition with your colleagues. Your idea is to add line numbers as known from Basic. None of your colleagues has that in a language. With that you'll be king (or queen) - but not among Carrot developers. It's important to realize that acceptance of contributions doesn't depend on the intellectual reputation of features. Formalized lambda expressions fit as bad as line numbers when it comes to the Perl 5 implementation.
- Any contribution must follow the existing coding style.
- Consider the high pace of development speed.
- The form of contribution should match its complexity.
- Specify your expectations (unless obvious). Is your contribution meant for integration into the core of Carrot? Or is it just an demonstration of potentials? Or do you plan to manage a Carrot extension separately from the main Carrot code base?
Anonymous contributions are not accepted for a variety of reasons. You must posses the intellectual property rights for your contributions and you must be willing to and you must be able to put them under exactly the same license terms as Carrot (MPL 2.0) when submitting.
Note that a written confirmation in form of a fax might be required one day.
If you want to contribute anonymously or the IP rights are not clear or you don't want to use Carrot's licensing terms, then you can still develop code. But its distribution is then up to you and your contribution cannot be integrated into the core of Carrot.
This includes tab indentation, block modifier compatible blocks, enough parenthesis for visual jumping, speaking names, arrays and hashes only as references. Contributions will rather be discarded than fixed in these regards.
It might be not obvious that the text of capabilities and effect has a limitation of 64 characters.
Contributions should rather be finished by this afternoon. Anything later might not match the code base any longer. Merge? Perl code is cheap, suggestions are rather re-written than re-factored to fit. Though it's not always that extreme.
It might sound ironic, but what makes Carrot attractive is the code which was discarded. Be prepared that your contribution is discarded soon. It's a matter of quality progress.
If you contribute by e-mail attachments, then make sure to use a specific subject. 'Typo' is not sufficient even for a one-line patch. 'Typo "annoymous" should read "annonymoos".' is slightly better, but best is 'Typo "annonymous" should read "anonymous" according to Websters'. Use the saved overhead of e-mail communication for your own quality control.
Single typing mistakes can be submitted by attaching a diff to an e-mail. Diffs should be relative to /home/mica_environment or /home/mica_environment/program_modules/perl.
Systematic typing mistakes must be submitted as a substitution pattern for utilities/re_substitute.pl. Same goes for any re-formatting - must be an scripted solution, not a diff. Remember this is Perl.
Newly added files might be submitted in a compressed .tar archive the first time.