Weekly Releases: March Roadmap, 1.6rc2.5, 1.7.1

[Richard D. Worth]

Team,

As announced in February: http://blog.jquery.com/2009/02/12/jquery-ui-17-is-the-new-16/ , starting this month (March) we're doing weekly releases (it's actually bi-weekly releases on two different branches, alternating weeks). Our first was last week with 1.7. Yay! From now on we'll alternate with preview and stable bug fix releases. This means:

March 11: 1.6rc2.5
March 18: 1.7.1
March 25: 1.6rc2.6 or 1.6final
April 1: 1.7.2

Releases are scheduled for Wed. morning. Nothing will block a release. The trunk needs to be stable enough that the release can happen. Always. Not the day of, not the day before. Instability that could otherwise block the release needs to remain in a ticket patch or a development branch. If something isn't finished or ready, the release goes on, and the feature or fix can be worked on for the next release, 2 weeks later.

1.6rc2.5 to 1.6 final
1.6rc2.5: Tomorrow we'll release 1.6rc2.5. This will be 1.6rc2 plus any bug fixes that were done for 1.6rc3 not including migration to the new jQuery UI CSS Framework, and not including API changes. No new code will be written for this initial preview release. It will simply be a merging of selected fixes (drawing a line in the svn revision history for each plugin). This will provide a baseline against which the team and community can develop and test against for the next two weeks, in preparation for 1.6 final.

1.7.1, 1.7.2 etc.
As stated on the Development and Planning wiki ( http://wiki.jqueryui.com/FrontPage#status ), stable bug fix releases will not be developed in the trunk, but in a branch. This is only kind of true, depending on how you look at it. Let me explain. Assume a bug is found today in 1.7. This bug is filed against 1.7 and the milestone is set to 1.8 (not 1.7.1). The bug is worked on and fixed in the trunk (currently version 1.8pre). After this point, the bug can be considered for inclusion in the next stable bug fix release (if another one happens). This means development won't be done on the 1.7.x branch itself. Rather specific crtical fixes will be merged from the trunk to the branch. This accomplishes a few things

- ensures a stable bug fix release can't be blocked by something that's in the milestone, but not yet completed
- ensures changes happen in both the trunk and the branch
- allows for development to start on the next major release (1.8) without waiting for the last stable bug fix release (1.7.3? 1.7.4?)
- ensures only the most critical and blocker fixes are included in the stable bug fix release

Please let me know if you have any questions or feedback. Thanks.

- Richard

[Cloudream]

This makes our versions have different meaning against jQuery core. I think minor versions should include all bug fixes which don't change API or add options, even huge performance increase but not change API/behaviors. This may increase major release stableness, otherwise we have to contain much code change in major release, and it sounds we won't have a really stable release whichever major or minor release.    Major releases include new widgets/new options/API change.

[Cloudream]

I mean in major releases, old widgets are stable, but new widgets not. And minor release only contains critical bugs fixed, new widgets are still unstable. Why do we still need minor release?

[Richard D. Worth]

On Tue, Mar 10, 2009 at 11:41 AM, Cloudream <clou...@gmail.com> wrote:

On Tue, Mar 10, 2009 at 8:49 PM, Richard D. Worth <rdw...@gmail.com> wrote:

Team,

As announced in February: http://blog.jquery.com/2009/02/12/jquery-ui-17-is-the-new-16/ , starting this month (March) we're doing weekly releases (it's actually bi-weekly releases on two different branches, alternating weeks). Our first was last week with 1.7. Yay! From now on we'll alternate with preview and stable bug fix releases. This means:

March 11: 1.6rc2.5
March 18: 1.7.1
March 25: 1.6rc2.6 or 1.6final
April 1: 1.7.2

Releases are scheduled for Wed. morning. Nothing will block a release. The trunk needs to be stable enough that the release can happen. Always. Not the day of, not the day before. Instability that could otherwise block the release needs to remain in a ticket patch or a development branch. If something isn't finished or ready, the release goes on, and the feature or fix can be worked on for the next release, 2 weeks later.

1.6rc2.5 to 1.6 final
1.6rc2.5: Tomorrow we'll release 1.6rc2.5. This will be 1.6rc2 plus any bug fixes that were done for 1.6rc3 not including migration to the new jQuery UI CSS Framework, and not including API changes. No new code will be written for this initial preview release. It will simply be a merging of selected fixes (drawing a line in the svn revision history for each plugin). This will provide a baseline against which the team and community can develop and test against for the next two weeks, in preparation for 1.6 final.

1.7.1, 1.7.2 etc.
As stated on the Development and Planning wiki ( http://wiki.jqueryui.com/FrontPage#status ), stable bug fix releases will not be developed in the trunk, but in a branch. This is only kind of true, depending on how you look at it. Let me explain. Assume a bug is found today in 1.7. This bug is filed against 1.7 and the milestone is set to 1.8 (not 1.7.1). The bug is worked on and fixed in the trunk (currently version 1.8pre). After this point, the bug can be considered for inclusion in the next stable bug fix release (if another one happens). This means development won't be done on the 1.7.x branch itself. Rather specific crtical fixes will be merged from the trunk to the branch. This accomplishes a few things

- ensures a stable bug fix release can't be blocked by something that's in the milestone, but not yet completed
- ensures changes happen in both the trunk and the branch
- allows for development to start on the next major release (1.8) without waiting for the last stable bug fix release (1.7.3? 1.7.4?)
- ensures only the most critical and blocker fixes are included in the stable bug fix release

This makes our versions have different meaning against jQuery core.

I'm not sure I see a difference, but if there is one, it's one I can live with. This is a new model, for sure. If we focus on a new major release every 2-3 months (instead of 6-9) we can't spend the first 4-6 weeks in cautious limbo. That means from day 1 after a final release we have to be able to move ahead with the next major version, but without affecting the stability of the stable branch. 1.7 may have 1 minor release (2 weeks). It may have 5 (10 weeks). We won't know until we're there. But that entire time, the trunk marches on. We can't simply release the trunk as 1.7.1, 1.7.2, etc. Otherwise each successive minor release would have more and more change, where it should have less and less.
 

I think minor versions should include all bug fixes which don't change API or add options, even huge performance increase but not change API/behaviors.

Major changes should go in major releases. This will allow sufficient time for review and testing, and also pose less risk of regressions which would require another (otherwise unneeded) minor release.

- Richard

[Richard D. Worth]

Stable is what we make of it. If each minor release has less change than the one before, there will be an increase of stability.

As far as old widgets vs. new widgets, I think this just gets at having sufficient review, testing, and use in preview releases (alphas, betas, rcs). When we hit a final release, a brand new widget should be just as final release-ready as any others, otherwise it shouldn't be in the release. In any case, that's what we released, and that's what we have to support. But if major changes are needed to improve it, those will require a major release.

- Richard

[BigFoot]

Does UI 1.7.1 released?

[BigFoot]

Does 1.7.1 released?

On Mar 10, 8:49 pm, "Richard D. Worth" <rdwo...@gmail.com> wrote:
> Team,
>

> As announced in February:http://blog.jquery.com/2009/02/12/jquery-ui-17-is-the-new-16/, starting

> this month (March) we're doing weekly releases (it's actually bi-weekly
> releases on two different branches, alternating weeks). Our first was last
> week with 1.7. Yay! From now on we'll alternate with preview and stable bug
> fix releases. This means:
>
> March 11: 1.6rc2.5
> March 18: 1.7.1
> March 25: 1.6rc2.6 or 1.6final
> April 1: 1.7.2
>
> Releases are scheduled for Wed. morning. Nothing will block a release. The
> trunk needs to be stable enough that the release can happen. Always. Not the
> day of, not the day before. Instability that could otherwise block the
> release needs to remain in a ticket patch or a development branch. If
> something isn't finished or ready, the release goes on, and the feature or
> fix can be worked on for the next release, 2 weeks later.
>

> *1.6rc2.5 to 1.6 final*

> 1.6rc2.5: Tomorrow we'll release 1.6rc2.5. This will be 1.6rc2 plus any bug
> fixes that were done for 1.6rc3 not including migration to the new jQuery UI
> CSS Framework, and not including API changes. No new code will be written
> for this initial preview release. It will simply be a merging of selected
> fixes (drawing a line in the svn revision history for each plugin). This
> will provide a baseline against which the team and community can develop and
> test against for the next two weeks, in preparation for 1.6 final.
>

> *1.7.1, 1.7.2 etc.*
> As stated on the Development and Planning wiki (http://wiki.jqueryui.com/FrontPage#status), stable bug fix releases will

[Richard D. Worth]

I'm finishing up the release right now, merging these changes:

http://wiki.jqueryui.com/Proposed-tickets-for-171

By tonight it will be tagged and zipped. The release notes and announcements will go out tomorrow once the website is updated.

- Richard

On Wed, Mar 18, 2009 at 7:05 PM, BigFoot <hui...@gmail.com> wrote:

Does UI 1.7.1 released?

[huixiu]

Thanks a lot.