This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: serial_devio renamaed to cyg_serial_devio


>>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes:

    >> I do not think there is any easy way of achieving this at
    >> present.

    Andrew> OK. Lets think about the future. The aim of using packages
    Andrew> is so that 3rd parties can develop there own packages
    Andrew> which can be plugged into the standard distribution.
    Andrew> Things change, move on, and are no longer compatible. As
    Andrew> this has shown you sometimes need the version information
    Andrew> to work out what to do to make things work with different
    Andrew> versions.

Incompatible interface changes between versions, especially minor
releases, should be avoided. The original name serial_devio was wrong,
there should have been a prefix such as cyg_ in there from the
beginning to reduce the possibility of name clashes. In practice
getting all these things right takes time.

Strictly speaking the serial renaming should have involved a major
version upgrade, to V2.0, but we are not set up just yet to release
core packages with different version numbers. Such functionality will
be more and more important in future: it is quite likely that some
packages, e.g. platform HAL's, will not change at all between core
releases; there is no point in having separate installed versions x
and y of a package when the two are identical. This will require
enhancements to the release system and to the administration tools.

However some way of coping with interface changes is desirable.

    Andrew> It seems to me there are two ways to do this, which are
    Andrew> not mutually exclusive. If there are big changes you
    Andrew> distribute multiple packages and let CDL work out the
    Andrew> dependances and pick the correct package to use. If the
    Andrew> changes are minor, as in this cause just one variable
    Andrew> name, #ifdef seems a good way to go.

Agreed.

    >> What might be possible is for the configuration tools to generate
    >> additional #define's along the lines of:
    >> 
    >> #define CYGPKG_IO_SERIAL v1_3_5
    >> #define CYGPKG_IO_SERIAL_VERSION_MAJOR 1
    >> #define CYGPKG_IO_SERIAL_VERSION_MINOR 3
    >> ...

    Andrew> Sounds good.
 
    >> I am not quite sure what to call the versioning levels after major or
    >> minor, there could be any number of these.

    Andrew> CYGPKG_IO_SERIAL_VERSION_VERY_MINOR? You have to draw the
    Andrew> line somewhere. 3 levels seems enough to me.

    >> Also versions may include letters or text, e.g. 1.3.5beta

    Andrew> Specify that any trailling text are removed to leave an
    Andrew> integer?

    Andrew> So, do we need this sort of versioning features? Is this a
    Andrew> good approch?

Unless somebody comes up with a better suggestion, or discovers a
major flaw in this approach, I think something along these lines is
worthwhile. I'll add it to the libcdl TODO list, which unfortunately
is rather longer than I would like. If this is proving a major problem
for you, and since Ascom is a paying customer, you may want to file a
formal problem report to get its priority raised.

Bart

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]