I'm not going to make it for the release date for 2.0, which was next monday,
and I'm delaying it for 2 weeks. I'll be abroad next week with limited
internet access, and I need another week of polishing before it's presentable
to a wider audience.
It was an extremely tight deadline, and I was occupied by bugs creeping in on
the 1.x mainline, which still has priority for current users.
The website redesign has also not yet taken off. Markus and Sylvain have
already done a great job in transforming the -dev workshop decisions into
code. I'll try to be as responsibe as possible to merge requests. My personal
goal is to polish the cmake system on the component side, in order to quickly
generate and build components. Adolfo has taken care of the needed
export/import logic in cmake. We can try an rc1 by the end of next week, as an
exercise to release the whole orocos-toolchain, and not only rtt. This will
require some coordination on gitorious. I would prefer common branch names
across all projects, and also a common tag name for the release (candidate).
Maybe Sylvain has an idea on how too do and choose this, such that autoproj
can pull it ?
Peter
RC1 (non-)news
Another thought on the branching of 2.0
I'd like 'master' to be the stable branch. I.e. I would like it to be
the one from which people that want "cutting-edge but not completely
experimental stuff" could track.
Thoughts ?
RC1 (non-)news
I like this approach, too. Master is stable but cutting edge.
Experimental, probably-not-working-or-even-compiling stuff is in feature
branches. Something like the centralised workflow.
http://progit.org/book/ch5-1.html
Geoff
On 16/08/10 16:57, Sylvain Joyeux wrote:
> Another thought on the branching of 2.0
>
> I'd like 'master' to be the stable branch. I.e. I would like it to be
> the one from which people that want "cutting-edge but not completely
> experimental stuff" could track.
>
> Thoughts ?
>
RC1 (non-)news
[please don't top post]
On Aug 16, 2010, at 04:00 , Geoffrey Biggs wrote:
> I like this approach, too. Master is stable but cutting edge.
> Experimental, probably-not-working-or-even-compiling stuff is in feature
> branches. Something like the centralised workflow.
>
> http://progit.org/book/ch5-1.html
>
> Geoff
>
> On 16/08/10 16:57, Sylvain Joyeux wrote:
>> Another thought on the branching of 2.0
>>
>> I'd like 'master' to be the stable branch. I.e. I would like it to be
>> the one from which people that want "cutting-edge but not completely
>> experimental stuff" could track.
>>
>> Thoughts ?
Either the centralised workflow or the existing integration-manager workflow is fine with me.
On the topic of branch names, can I suggest we go with fairly standard practice (as used by Linux, git developers, etc). "next" or "next-topic" for branches ready for integration into the stable master. And "pu" (proposed updates) for things ready for others to try, but not stable enough to go into the "next" series.
http://members.cox.net/junkio/git/MaintNotes.html
http://www.kernel.org/pub/software/scm/git/docs/howto/maintain-git.txt
S
RC1 (non-)news
On 08/13/2010 06:46 PM, Peter Soetens wrote:
> I'm not going to make it for the release date for 2.0, which was next monday,
> and I'm delaying it for 2 weeks. I'll be abroad next week with limited
> internet access, and I need another week of polishing before it's presentable
> to a wider audience.
>
> It was an extremely tight deadline, and I was occupied by bugs creeping in on
> the 1.x mainline, which still has priority for current users.
>
> The website redesign has also not yet taken off. Markus and Sylvain have
> already done a great job in transforming the -dev workshop decisions into
> code. I'll try to be as responsibe as possible to merge requests. My personal
> goal is to polish the cmake system on the component side, in order to quickly
> generate and build components. Adolfo has taken care of the needed
> export/import logic in cmake. We can try an rc1 by the end of next week, as an
> exercise to release the whole orocos-toolchain, and not only rtt. This will
> require some coordination on gitorious. I would prefer common branch names
> across all projects, and also a common tag name for the release (candidate).
> Maybe Sylvain has an idea on how too do and choose this, such that autoproj
> can pull it ?
>
autoproj can handle any kind of branching/tagging scheme. It is just
easier (but not mandatory) if all repositories
FYI, I'll be in Japan starting in two weeks and then I have a month of
vacations from the 4th september onwards.
In any case, I will send details on how to bootstrap the
orocos-toolchain using autoproj today or tomorrow, and prepare
documentation hopefully before the end of this week. It would be nice if
you guys could test all of that before I leave ;-)
I'm currently discovering bugs in orogen for 2.x since I'm starting to
port modules from our repositories.
Sylvain