Distributed SCM is definitively the way to go if you're looking in having more dispersed contributors, if the contribution is going to be through some form of code submission and integrated by you then any SCM will do I guess. Mercurial is indeed a great tool, I've found it more easily to use than Git although both require some shift in the way one think when it comes about SCM... kinda your mileage might vary, peoples that like to think in check-out(even lock)/check-in terms might find some discomfort with DSCM.
Any source control you put in place you'll still have to provide some sort of archive based releases for peoples that just want to take the code and use it, some release management with versioning could help.
As for documenting for low-level developers like me UML diagrams and inline code documenting will do... check out Natural Docs, really good for API level technical documentation. Videos and webex presentations is something that some prefers, I do not find enough time to get through those and as there are no bookmarks and ability to jump from one place to another easily I find those of less use, just personal preference though.
marianedu schrieb:
check out Natural Docs, really good for API level technical documentation.
Did you configure it to work well with procedural and OO ABL code? Did you set that up as one or two languages?
Natural Docs is more about 'natural' documentation, as long as you write the comments the way it expect you can do pretty much what you want with it... there is no 'full-language' support for Progress ABL, although it can't be that hard to have that implemented (python code does not kill) I haven't found the drive to do that. As I've said, it's more about documenting that simply scraping the code and get the list of internal entries (methods/procedures)... if those are not documented at all, what use one can find from simply having them listed there?
I have since switched over to AutoDox2
(http://www.joanju.com/autodox2/index.php) which uses proparse and
javadocs, I believe that some portions of Progress are using it.
just out of curiosity my good sir, in which way is it any different or better?... other than not being open-source
marianedu wrote:
just out of curiosity my good sir, in which way is it any different or better?... other than not being open-source
AETF uses AutoDox2, largely because it just works. It produces output that's comparable with javadocs. At the time we didn't have the resources (time, priorities) to get another solution working.
-- peter
Thanks Peter, nothing wrong with it... I too love ANTLR and John did a great job with the Progress grammar. Joke let aside I knew Julian tried Natural Docs at some point, that's why I've ask what is that AutoDox2 provides more to make it a better choice?
AutoDox2 is much more orientated towards progress - no language
definitions to contend with, and packages / classes are automatically
dealt with. So are method names etc.
Oh, and I also want to support a Progress community member
There are a couple of things that came up as a result of my testing
and using AutoDox2 that John Green (the author) got right onto for me,
so support is second to none.
Oh, and I also want to support a Progress community member
There are a couple of things that came up as a result of my testing
and using AutoDox2 that John Green (the author) got right onto for me,
so support is second to none.
+1 and +1 (one fore each paragraph )
-- peter
good to know that, this means there is still hope for progress related developer tools