Release schedule (RTT/OCL/KDL)

It's been almost three months since the 1.4.0 releases and quite a number of
issues have been fixed in RTT and OCL. No major features have been added yet
on the RTT branch. OCL had more feature additions and even some new
components for camera vision.

There are 22 bugs open on the RTT, but none are critical, or are only feature
requests. The most important fixes are

481 connectPorts only partially connects two read ports
482 Corba's createMethodAny and createCommandAny methods broken
486 SimulationThread locks up system under Xenomai 2.4

and a lot of documentation and unit testing updates were done as well. For
OCL, more bugs are open (about 32). I want these issues fixed by 1.4.1:

511 Error when creating TimerComponent
500 Howto load external toolkits
311 ReportingComponent should use ORO_SCHED_OTHER by default
315 Reporting and autotrigger

There are lots more issues to be addressed in OCL, but most of them can only
be fixed in a 1.6 release, as they require API additions. If you don't agree,
post a note. Also the RTT has some outstanding issues which require a 1.6
release. I'll start tagging these features in Bugzilla with a '1.6.0'
milestone. These 1.6 features can be committed on trunk the coming month. A
RTT/OCL 1.6 release can be expected by the end of march.

For OCL, there's also the KDL dependency for the motion components, which
aren't packaged yet. I'm asking the motion control people to apply the
necessary fixes in trunk/ocl/debian if they want them released as well. I'll
also require a tested and 'dpkg-buildpackage' ready kdl branch.[*] If one of
these things fails, I'll revert to the current packaging status.

From 1.4.1 on, I'll start releasing the Debian packages from the rtt-1.4 /
ocl-1.4 branches, such that builders from source have the same fixes as the
Debian package users. Expect the branches to be up to date by 22 Feb. and the
releases by 29 Feb.

Peter

[*] ready KDL branch: Choose a library so-version number which reflects the
stability of the API: For example, libkdl.so --> libkdl.so.1.0 means you
won't remove or rename functions in the 1.x versions. If you can't guarantee
that, use libkdl.so --> libkdl.so.0.99 until you're sure. Adding
functions/classes is allowed in each 1.x -> 1.y release. Set the
debian/changelog accordingly.

Release schedule (RTT/OCL/KDL)

On Friday 29 February 2008 13:06:27 Ruben Smits wrote:
> > [*] ready KDL branch: Choose a library so-version number which reflects
> > the stability of the API: For example, libkdl.so --> libkdl.so.1.0 means
> > you won't remove or rename functions in the 1.x versions. If you can't
> > guarantee that, use libkdl.so --> libkdl.so.0.99 until you're sure.
> > Adding functions/classes is allowed in each 1.x -> 1.y release. Set the
> > debian/changelog accordingly.
>
> * Can i change function arguments from 1.x to 1.y??

Normally not. You need to supply a new function with the new arguments.

I was actually mixing two things: SO_VERSION and the 'Orocos version' scheme.
* The 'Orocos version' scheme dictates that every 1.x release is
upwards 'source compatible', meaning that you can recompile an 1.0
application for 1.6 and it will still compile/work. You can not move headers,
rename functions, change arguments etc. otherwise, the application source may
fail to compile.
* The SO_VERSION talks about 'binary compatibility', which means you can't
change function names, arguments or even add an extra class variable within
an SO_VERSION. In Orocos libraries, the SO_VERSION is for example '1.4'. This
means that every 1.4.x release is binary compatible, thus you don't need to
recompile your program if there's a new 1.4.x library version.

For the SO_VERSION, there's no exception whatsoever, because if you break the
rules, programs will segfault. So 1.4.1 -> 1.4.2 ONLY contains bugfixes in
the .cpp files, no headers are changed !
For the 'Orocos version' (1.x) source compatibility may be given up in extreme
cases, for example, a given function or class could have never worked and is
just removed or replaced.

>
> * I'm still looking for a good buildfarm with orocos-rtt-gnulinux,
> orocos-rtt-xenomai and orocos-rtt-lxrt packages installed to build the
> orocos-kdl packages for debian/ubuntu

The RTT/OCL 1.4.1 release won't be ready today due to other, harder deadlines.
Sorry if you were counting on this... I'll prepare the rtt-1.4 and ocl-1.4
branches ASAP.

Peter

Release schedule (RTT/OCL/KDL)

A Divendres 29 Febrer 2008, Peter Soetens va escriure:
[...]
>
> > * I'm still looking for a good buildfarm with orocos-rtt-gnulinux,
> > orocos-rtt-xenomai and orocos-rtt-lxrt packages installed to build the
> > orocos-kdl packages for debian/ubuntu
>
> The RTT/OCL 1.4.1 release won't be ready today due to other, harder
> deadlines. Sorry if you were counting on this... I'll prepare the rtt-1.4
> and ocl-1.4 branches ASAP.

Peter,

now we have xenomai and rtai (maintained) at debian sid. It would be easy to
make a backport, so please, use the same names of the packages for rtt.

In the case of rtt-sources, you should add:

libxenomai-dev, libxenomai1, librtai-dev, librtai1

the same for kdl ... I should look on it again.

Regards,

the "very helpful user"

;-)

Release schedule (RTT/OCL/KDL)

On Tuesday 04 March 2008 17:13:38 Leopold Palomo-Avellaneda wrote:
> A Divendres 29 Febrer 2008, Peter Soetens va escriure:
> [...]
>
> > > * I'm still looking for a good buildfarm with orocos-rtt-gnulinux,
> > > orocos-rtt-xenomai and orocos-rtt-lxrt packages installed to build the
> > > orocos-kdl packages for debian/ubuntu
> >
> > The RTT/OCL 1.4.1 release won't be ready today due to other, harder
> > deadlines. Sorry if you were counting on this... I'll prepare the rtt-1.4
> > and ocl-1.4 branches ASAP.
>
> Peter,
>
> now we have xenomai and rtai (maintained) at debian sid. It would be easy
> to make a backport, so please, use the same names of the packages for rtt.

I'll look into it. But are the rtai packages useful/working ? Also, we are
building RTT/OCL for Debian Etch, not sid. I don't want to force users
putting the sid path in their sources.list file in order to get RTT
installed. The only solution I see there is building these packages on/for
Etch and putting them in our own repository...

Do you know how the tuxcnc Xenomai packages related to Debian sid ?

Peter

>
> In the case of rtt-sources, you should add:
>
> libxenomai-dev, libxenomai1, librtai-dev, librtai1
>
> the same for kdl ... I should look on it again.
>
>
> Regards,
>
> the "very helpful user"
>
> ;-)

Release schedule (RTT/OCL/KDL)

A Dimarts 11 Març 2008, Peter Soetens va escriure:
> On Tuesday 04 March 2008 17:13:38 Leopold Palomo-Avellaneda wrote:
> > A Divendres 29 Febrer 2008, Peter Soetens va escriure:
> > [...]
> >
> > > > * I'm still looking for a good buildfarm with orocos-rtt-gnulinux,
> > > > orocos-rtt-xenomai and orocos-rtt-lxrt packages installed to build
> > > > the orocos-kdl packages for debian/ubuntu
> > >
> > > The RTT/OCL 1.4.1 release won't be ready today due to other, harder
> > > deadlines. Sorry if you were counting on this... I'll prepare the
> > > rtt-1.4 and ocl-1.4 branches ASAP.
> >
> > Peter,
> >
> > now we have xenomai and rtai (maintained) at debian sid. It would be easy
> > to make a backport, so please, use the same names of the packages for
> > rtt.
>
> I'll look into it. But are the rtai packages useful/working ?

I don't know. As I can say is that now there's a new version and seems that
the packages are "more" maintained and useful I think ...

> Also, we are
> building RTT/OCL for Debian Etch, not sid. I don't want to force users
> putting the sid path in their sources.list file in order to get RTT
> installed. The only solution I see there is building these packages on/for
> Etch and putting them in our own repository...

Ok, I agree. At least, xenomai that I did it, it's very easy do a backport. I
can do it for orocos if you need it.

> Do you know how the tuxcnc Xenomai packages related to Debian sid ?

I don't know. As I can say is that Roland have worked on the official packages
based on the Paul's work (tuxcnc), solving some issues and applying some
patches and points that I sent him.

The idea of Roland is that the debian packages is the lib and dev and the
patches (as the Pauls debs did) and no kernel-image provides. So, provide a
kernel image will be needed.

Regards,

Leo