[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
> | No, the branch happens *after* release, for maintenance.
> Oh, I thought it (for the n.m releases, rather than the point releases)
> worked the same as the major releases, where the branch happened, and
> then was tested (fixed if required) and eventually released, while the
> base release (netbsd-6 in this case) could keep on being improved.
Nope, 6.1 will just be a tag on the netbsd-6 branch. When that
tag is set, the netbsd-6-1 branch will be created, and the first
release along that branch (if it happens) wil be designated 6.1.1.
> What happens now if someone requests a netbsd-6 pullup of something that
> is not suitable for 6.1?
The request gets marked as "stalled" in our request queue until
after the 6.1 release has happened, much the same way as in the
process leading up to 6.0.
> (Say a new version of gcc was incorporated, or similar). Does
> all of netbsd-6 just have to stall on the pullup for however
> long it takes for 6.1 to eventually become clean enough to
> | 6.1_RC2 came out last week.
> yes, I know, that's when I went looking to see what tag I should use
> to checkout and build that one, and then be able to keep up with any
> improvements, but stick in the 6.1 tree (I'll checkout and build what
> will become 6.2 (someday perhaps) elsewhere).
Up until 6.1 is released, the branch to track if you want to
apply the pull-ups as they are processed is netbsd-6. When 6.1
is released, netbsd-6 will be the branch which will lead to 6.2,
and will be marked 6.1_STABLE when 6.1 is released.
> Then I couldn't find one - so I used netbsd-6-1-RC2 but with
> that one I'm not going to get RC3 without manual intervention.
Right. It sounds like you should stick to netbsd-6 instead,
until netbsd-6-1-RELEASE exists, at which point you can choose
which branch you want to follow onwards.
Main Index |
Thread Index |