the issue is version numbers are only useful IF they are allocated consistently, and that I think will be impossible to achieve in the community library... as you rightly point out, there we cannot enforce any rules.... and we also have to make it easy for all contributors.
first on reflection, my example using app versions, was not a good ideas....
I think using a sequential timeline is the better way... it requires no user intervention.
I agree there are a number of different issues..
lets consider the problem in a few parts...
a) ensure we can retrieve the correct objects for an old patch
b) retrieving/using old objects
(a) a patch uses libraries, we could when we save the patch store the commit id of the head of each library. this means for any patch you know exactly which libraries (repo) are used, and the point in their history they were at .
(b) retrieving, you can retrieve any object easily if you know the commit id of the head.
the next trick is , how do you use that code?
my straw man said, retrieve it, and put it in an embedded object, but thats only one solution, theoretically you load/stream directly from the repo to use... or if that turned out to be slow, you could 'cache' the file (its temporary only, not like a obsolete directory which is permeant)
easy, the commit log tells you exactly what changes have occurred and when....
the change log can be used to describe to the user what changed and when, and as we are doing object by object, they can choose to upgrade one or all, or any combo
the could even upgrade in steps i.e. not do that last 'big api' change yet, but leave for another day.
so why use vcs, what does it buy you , over a 'roll your own'... to be more precise, what features might you use , that you would also have to add to a roll your own solution?
well the main thing is commit history.... comments on changes, dates and times of those changes, how those changes related to other changes.
(I don't agree objects are always isolated, some objects change together...)
also I think you have a misunderstanding in my approach...
I know in conventional coding, we checkout a whole commit, i.e. many files in one go... but thats not how I'm suggesting to use vcs here, Im saying use the individual history an object has.
the other advantage is, it has a toolset in place....
sure most users may not need anything advance, but the ability for an inquiring mind, to be able to diff objects over time, or query the changes between two dates is useful.... especially when debugging why your patches behaviour has changed.
finally... the 'freebies' of a vcs...
i imagined when I created the libraries, that I might add features like 'freeze' , this would basically use tags to allow users to have a snapshot in time of the libraries... so they can freely go back and forth e.g. for performances.
or perhaps even add 'user level' support for private repos, so such that an end user can backup their own patches too the cloud, and then retrieve old versions.
of course, my basic premise here is simple, use the power of a vcs, but hide it from the user... wrap it so they don't need to know the complexities.
vcs are great for managing change over time, thousands of hours of development has been done on them to do just that, and they are used by 100,000s of users daily so are robust....
for me, id say I think either approach can work? do you agree?
(or do you think there is a fundamental flaw using a vcs which means it cannot work?)
I've suggested the advantages of the vcs approach.
the advantage i can see for a roll your own are, you aren't tied so much to an implementation/external... perhaps on the surface it appears simpler (as it self contained, so no knowledge of git/jgit needed)
dev effort, id say its pretty similar
anyway, thats just my views... I think both could work, really its a choice....