On 01-08-24 18:14:23 CEST, Massimiliano Pala wrote:
> > openca/
> > [...]
> > openca/src/
> > openca/src/modules/
> > openca/src/modules/openca-x509/
> > openca/src/modules/openca-openssl/
> > openca/src/modules/openca-crl/
> > [...]
> >
> > on the directory level and cvs branches othogonal to them.
> > but i would accept michael's directory layout if mismaps with cvs
> > branches are to be expected.
>
> I am indeed not a CVS expert, if you think this SHOULD be done you could
> (I hope) take in charge of planning the changes...
i had this question in the back of my mind for a couple of days now, but
i'm still not sure what best to suggest.
cvs is neither very good at tracking structural changes (because it
hasn't got versioning of directories), nor is merging between branches
very comfortable (i believe the only way to keep track is to use lots of
labels).
(clearcase can do both, but it's a horribly expensive piece of
proprietary software.)
having fs directories instead of cvs branches helps with the first
cvs shortcoming, for the second it doesn't matter much.
so, the choice is mostly up to you: what do you want {to,want me to} do?
> > > My point is that modules development is to be separated from the main
> > > project so we can still use the 'openca-xxx' for release development
> > > and drop the openca/ main cvs dir but I would continue to have
> > > modules cvs directories in the main cvs tree (and not in openca-xxx
> > > subdirs).
> >
> > how are we gonna track which modules' versions fit which core-openca
> > versions?
>
> This is a good point. The easy way is to have the major release number
> to be the "compatibility" number so as to have all the 1.xx.xx versions
> of a module to be compatible, when major "incompatible" changes are made
> then the major version number should be increased ( i.e. 2.xx.xx ).
>
> This would express compatibility issues within a module history but not
> with other modules...
along with moving the modules to openca(-x.y)/src/modules/, i would also
get rid of the module version numbers, i think they only confuse people,
which IMHO are more likely to think of openca as a whole and not as a
wrapper around a collection of modules.
the modules then simply belong to the openca version indicated by either
the openca-x.y directory or cvs branch they are in, respectively.
rj
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/openca-devel
