Thread: [OctDev] state of octave-forge code

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Should the scripts in CVS be compatible with Octave 2.1.70, or is it
OK to use functionality from the 2.9.x branch?

Regards
Stefan

Use 2.1.70 for now.

After the next release we can purge any pre-2.9.x code.  If somebody is 
interested in supporting 2.1.x code, they should create a branch after 
the next release.

-Paul

On Jun 9, 2005, at 4:35 AM, Stefan van der Walt wrote:

> Should the scripts in CVS be compatible with Octave 2.1.70, or is it
> OK to use functionality from the 2.9.x branch?
>
> Regards
> Stefan
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office 
> luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

With the new release out the door, I assume it is ok to make those
changes now?

Regards
Stefan

On Sun, Jun 12, 2005 at 03:23:26PM -0400, Paul Kienzle wrote:
> Use 2.1.70 for now.
> 
> After the next release we can purge any pre-2.9.x code.  If somebody is 
> interested in supporting 2.1.x code, they should create a branch after 
> the next release.
> 
> -Paul
> 
> On Jun 9, 2005, at 4:35 AM, Stefan van der Walt wrote:
> 
> >Should the scripts in CVS be compatible with Octave 2.1.70, or is it
> >OK to use functionality from the 2.9.x branch?
> >
> >Regards
> >Stefan

Yes, it is time for spring cleaning.

(1) Target 2.9.x code.  Remove #ifdefs which support older versions of 
octave.

(2) Remove functions that are duplicated in octave. For every function 
in the core matlab package, use texinfo docs, octave coding standards 
and write test cases.  These should be part of octave before the 3.0 
release.

(3) It would also be nice to reorganize the project into a package 
manager plus a set of independent packages.

Presumably we should maintain a separate branch in CVS for those who 
don't want to do the 2.9.x upgrade and are interested in backporting 
bug fixes.  That won't be me.

Also, I foresee having even less time for octave work in the near term, 
so if you see something on the list that you can address (such as 
helping new and occasional contributors get their code into 
octave-forge) please do so.

Thanks

	- Paul

On Jun 13, 2005, at 5:59 AM, Stefan van der Walt wrote:

> With the new release out the door, I assume it is ok to make those
> changes now?
>
> Regards
> Stefan
>
> On Sun, Jun 12, 2005 at 03:23:26PM -0400, Paul Kienzle wrote:
>> Use 2.1.70 for now.
>>
>> After the next release we can purge any pre-2.9.x code.  If somebody 
>> is
>> interested in supporting 2.1.x code, they should create a branch after
>> the next release.
>>
>> -Paul
>>
>> On Jun 9, 2005, at 4:35 AM, Stefan van der Walt wrote:
>>
>>> Should the scripts in CVS be compatible with Octave 2.1.70, or is it
>>> OK to use functionality from the 2.9.x branch?
>>>
>>> Regards
>>> Stefan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you 
> shotput
> a projector? How fast can you ride your desk chair down the office 
> luge track?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Octave-dev mailing list
> Oct...@li...
> https://lists.sourceforge.net/lists/listinfo/octave-dev
>

Paul Kienzle a =E9crit :

> Yes, it is time for spring cleaning.
>
> (1) Target 2.9.x code.  Remove #ifdefs which support older versions of=20
> octave.
>
> (2) Remove functions that are duplicated in octave. For every function=20
> in the core matlab package, use texinfo docs, octave coding standards=20
> and write test cases.  These should be part of octave before the 3.0=20
> release.
>
> (3) It would also be nice to reorganize the project into a package=20
> manager plus a set of independent packages.
>
> Presumably we should maintain a separate branch in CVS for those who=20
> don't want to do the 2.9.x upgrade and are interested in backporting=20
> bug fixes.  That won't be me.

I feel the main branch in the CVS should probably be the 2.9.x code, but=20
that might be too agressive at the start with octave 2.9 still=20
considered as unstable. For that reason I'd suggest creating a 2.1 and a=20
2.9 branch right now, where 2.1 branch will follow the MAIN branch at=20
the start, and when 2.9 goes into testing we merge the 2.9 branch into=20
the main branch.

There is rather a lot of spring cleaning to do...

D.

On Jun 13, 2005, at 8:21 AM, David Bateman wrote:

> Paul Kienzle a =E9crit :
>
>> Presumably we should maintain a separate branch in CVS for those who=20=

>> don't want to do the 2.9.x upgrade and are interested in backporting=20=

>> bug fixes.  That won't be me.
>
>
> I feel the main branch in the CVS should probably be the 2.9.x code,=20=

> but that might be too agressive at the start with octave 2.9 still=20
> considered as unstable. For that reason I'd suggest creating a 2.1 and=20=

> a 2.9 branch right now, where 2.1 branch will follow the MAIN branch=20=

> at the start, and when 2.9 goes into testing we merge the 2.9 branch=20=

> into the main branch.

If that is easy to do feel free to do so.

Having no experiences with branches I would keep it simple, using the=20
trunk for 2.9 and leaving it to the 2.1 folks to deal with branches.

- Paul

Paul Kienzle a =E9crit :

>
> On Jun 13, 2005, at 8:21 AM, David Bateman wrote:
>
>> Paul Kienzle a =E9crit :
>>
>>> Presumably we should maintain a separate branch in CVS for those who=20
>>> don't want to do the 2.9.x upgrade and are interested in backporting=20
>>> bug fixes.  That won't be me.
>>
>>
>>
>> I feel the main branch in the CVS should probably be the 2.9.x code,=20
>> but that might be too agressive at the start with octave 2.9 still=20
>> considered as unstable. For that reason I'd suggest creating a 2.1=20
>> and a 2.9 branch right now, where 2.1 branch will follow the MAIN=20
>> branch at the start, and when 2.9 goes into testing we merge the 2.9=20
>> branch into the main branch.
>
>
> If that is easy to do feel free to do so.
>
> Having no experiences with branches I would keep it simple, using the=20
> trunk for 2.9 and leaving it to the 2.1 folks to deal with branches.

It depends on really on what the people who will be developing the=20
changes want, so I wouldn't just do such a change, but raise a=20
discussion to see what others want...

D.

On 6/14/05, David Bateman <Dav...@mo...> wrote:
> Paul Kienzle a =E9crit :
>=20
> >
> > On Jun 13, 2005, at 8:21 AM, David Bateman wrote:
> >
> >> Paul Kienzle a =E9crit :
> >>
> >>> Presumably we should maintain a separate branch in CVS for those who
> >>> don't want to do the 2.9.x upgrade and are interested in backporting
> >>> bug fixes.  That won't be me.
> >>
> >>
> >>
> >> I feel the main branch in the CVS should probably be the 2.9.x code,
> >> but that might be too agressive at the start with octave 2.9 still
> >> considered as unstable. For that reason I'd suggest creating a 2.1
> >> and a 2.9 branch right now, where 2.1 branch will follow the MAIN
> >> branch at the start, and when 2.9 goes into testing we merge the 2.9
> >> branch into the main branch.
> >
> >
> > If that is easy to do feel free to do so.
> >
> > Having no experiences with branches I would keep it simple, using the
> > trunk for 2.9 and leaving it to the 2.1 folks to deal with branches.
>=20
> It depends on really on what the people who will be developing the
> changes want, so I wouldn't just do such a change, but raise a
> discussion to see what others want...

I think it partly depends on the plans for Octave 2.9. When will it
become the recommended stable version of Octave?

And it partly depends on how much work is needed to be make
Octave-Forge ready for 2.9.

I haven't run into any problems running Octave-Forge with 2.9.3.

Keith Goodman a =E9crit :

>I think it partly depends on the plans for Octave 2.9. When will it
>become the recommended stable version of Octave?
>
> =20
>

John has mentioned some time this summer as the release date for 3.0 a=20
couple of months ago. I'd say the very end of summer is realistic at the=20
moment. A testing release is vital before such a release and so I=20
wouldn't expect more than a couple of months before a testing version of=20
2.9.x, at which time it would make sense to start thinking about a new=20
release of octave-forge.

>And it partly depends on how much work is needed to be make
>Octave-Forge ready for 2.9.
> =20
>
octave-forge is already ready for 2.9.3 as you note... This is not the=20
issue. The issue is that there are many duplicate function in=20
octave-forge relative to octave that should be removed, and there are a=20
large number of version specific tests in octave-forge as Paul pointed=20
out that make the code rather crufty... The purpose of a 2.9 specific=20
version is to profit from the upcoming release of octave 3.0 to largely=20
simplify octave-forge..

Cheers
David

Thread: [OctDev] state of octave-forge code

A collection of packages providing extra functionality for GNU Octave

octave-dev