On 24 January 2011 11:32, Keith Clarke <[email protected]>wrote:
> > However, whilst a wiki might help with 'How-to' documentation, I'm not sure > it would be the ideal solution to address the core data and process > management issues here. There is a need for structure and clarity around > entities (platforms, controls, components, script features, etc), > relationships (e.g. the degree of feature support) and implications of > change. These suggest the need for cross-referencing, tables and therefore a > core 'database' to me. Indeed, many questions and information gaps (and > potential wiki content) are around inner vs. outer joins - "Does this > component run on this deployment?", "Exactly what does 'cross-platform' mean > for this component?" > Exactly! But I believe we can have all this without reaching out immediately for a database solution. The solution I am working on has the documentation and code both in the repository. That way you can simply rewind to any particular IDE engine release to see the documentation and code suitable for that environment. Moving forwards any new features added to the engine and IDE would be documented by the community based on the release notes, and linked to tickets for bug fixing. As the bugs get fixed and questions answered these would get moved into the documentation wiki. Official releases would be tagged, and users would be able to work within a tagged release branch, or in a beta environment branch. The thought is to use branches for different specific use cases. From pushing at the boundaries of what is possible with distributed version control and git in particular, it would appear that the technical infrastructure is there to support all these issues - but that the specific use case demands using branching and other features to deal with the particulars of multi-platform development. This approach will rely on getting the usability issues right, and shielding the intricacies of the repository from the causal developer - but in principle they should be able to work in a branch that is specific to a platform or combination of platforms. I should also note that as the code and documentation would be in the repository - this does not exclude the use of the sort of databases you indicate. The current implementation is going to use sqlite to hold both the repository itself and various indexes used to search it. I feel this can be built on. Ideally, in order for this to be of use for people with older licenses, I would import a historical series of snapshots, which would allow people with older versions to work. There are many aspects of this that I am unclear about, with regards to how branching and merging, and other features or distributed repositories can be used in this mix - but the initial benefits are simple and clear - shared collaborative code and documentation that is available offline and easy to customise to local needs. So, maybe a core database with relationships and structured data, could link > out to comments, extended commentary and other wiki-style verbose content to > answer formally structured questions such as - "How do I do function 'A' > with component 'B' if deploying to environment 'C'?", together with loosely > structured questions "What components could I consider buying to save > building functions 'x', 'y' and 'z'?". > I'm certainly open to building a database on top of the version controlled documentation and code. This db is more advanced that I am practiced at building, and if you have any tips / input that would be great. For now I am exporting the vital information that needs versioning as text files, and indexing these in sqlite. This should be a solid basis to build more extensive queries on. Back to my original question, it would have been nice to see in the RunRev > Store a simple table of which third-party components can be deployed where > but I guess anything that risks shattering the illusion of universality is > against RunRev's interests, so I won't hold my breath. ;-) > There is a sensitive issue for RunRev here - and an approach where the community can offer on a separate site an analysis of this issues, which is open to investigation by any interested party but clearly separate from marketing and / or official company policy is a way in which all parties can have their cheese and eat it. _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
