Feature support by deployment type - the state of the art?

[David Bovill]

On 24 January 2011 11:32, Keith Clarke
<keith.clarke at clarkeandclarke.co.uk>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.