octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3.2.x


From: Jaroslav Hajek
Subject: Re: 3.2.x
Date: Thu, 2 Oct 2008 07:56:00 +0200

On Wed, Oct 1, 2008 at 10:40 PM, John W. Eaton <address@hidden> wrote:
> On  1-Oct-2008, Jaroslav Hajek wrote:
>
> | On Wed, Oct 1, 2008 at 5:16 PM, John W. Eaton <address@hidden> wrote:
> | > On 23-Sep-2008, Jaroslav Hajek wrote:
> | >
> | > | On Tue, Sep 23, 2008 at 3:13 PM, John W. Eaton <address@hidden> wrote:
> | > | > On 23-Sep-2008, Jaroslav Hajek wrote:
> | > | >
> | > | > | Anyway, I don't think it's strictly necessary to have all the wanted
> | > | > | patches before the initial fork happens, we can just as well fork 
> now
> | > | > | (or in near future) and transplant the patches later if they arrive.
> | > | >
> | > | > What would be the purpose of the new branch if we are not ready for a
> | > | > release?
> | > | >
> | > |
> | > | So that patches that are not intended for 3.2.x could be applied to
> | > | development branch.
> | >
> | > I agree that this could be useful, but do we have any patches in that
> | > category now?  If possible, I'd prefer to branch after the 3.2.0
> | > release.
> | >
> |
> | Well, but if it's up to me to make the release, the I still need to
> | branch before doing it. My plan is:
> | 1. You tag a suitable revision in the development archive as the base
> | for 3-2-x branch.
> | 2. I'll clone that into 3-2-x repo at Thomas' site.
> | 3. Announce 3-2-x RC N ( = 1).
> | 4. Wait for reports.
> | 5. Fix possible problems, N++ and goto 3, or goto 6
> | 6. Announce the release as stable.
> |
> | Since the release is actually made at point 6, we still need to fork
> | before 3.2.0 is made. Patches may be transplanted at point 5. And
> | there is no problem if we want to transplant more patches between 2.
> | and 3.
> |
> | If you intend to do the 3.2.0 release under a different scenario, then
> | please clarify.
>
> I was planning to make the .0 releases, then allow branching at that
> point.  If that causes trouble, then we can branch before the
> release.
>

Fine, no problem.

> Or, if you would prefer to handle all releases, then you can do what
> you suggest above.  In step 5, do you expect to be making those
> changes and also pushing them to the main development branch?
>

No, I wanted the normal scenario: patches applied to main repo, I
transplant them to 3.2.x.

> But in any case, I don't think it is time to branch yet.
>

OK, that decision is up to you. Obviously, it should happen reasonably
shortly before the release.


-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

[Prev in Thread] Current Thread [Next in Thread]