Re: [TCLCORE] Tk release numbering

[Steve L. <st...@di...>]

Thanks for your perspective Don.   Here’s my thoughts ...

I strongly support decoupling Tcl and Tk,  to allow Tk to evolve more quickly in response to changes in windowing systems and graphics toolkits and to harness the enthusiasm of people who (from time to time) offer platform-specific enhancements

However I am concerned about divergent release numbers especially if we end up with different major release numbers. The reasons are mostly non-technical, being a combination of reasonable expectations set since Tcl/Tk 8.0 and also the difficulties associated with promoting and explaining Tcl 9.0 / Tk 8.7.  I am also less than enthusiastic about encoding the Tcl and Tk version numbers in the Tk library library file names.

So, my proposal is:

• we decouple Tcl and Tk
• we treat Tk as package (albeit under TIP control so not a true 3rd party package like SQLite)
• we always release a Tk with Tcl
• we may choose to make subsequent Tk releases as it evolves

In practice this would mean Tcl 9.0 / Tk 9.0, or just Tcl/Tk 9.0, and subsequent Tk 9.0.1, Tk 9.0.2, etc as Tk evolves faster.  Then Tcl 9.1 / Tk 9.1 and Tk 9.1.1, Tk 9.1.2.  I can see no argument that we must only increase the major Tk release number for incompatibilities, but in reality there are incompatibilities, such TIP 577 which has been reported as breaking 3rd party code.

-- Steve
On 5 Aug 2023 at 2:29 AM +0800, Donald G Porter via Tcl-Core <tcl...@li...>, wrote:
>
> There's a more foundational question to resolve.  Do we want to decouple Tcl and Tk?
>
> I would like to see Tcl and Tk decoupled.  I had the impression this was a broadly shared aim, but maybe not.  Let me set aside any debate on that point for now, and stipulate that decoupling is an aim we should pursue.
>
> Two decoupled projects will have different release calendars, and will then diverge in their release numbers.  This is inherent in decoupling, and the only real question is when to begin the separate numbering schemes.
>
> I submit that a new major release for one of the projects is an ideal time to make this shift.  For folks who've always known the projects as lockstep partners, diverging release numbers will seem disruptive.  It does also raise some new questions (which releases interoperate?), but these questions have well grounded, conventional answers.  And at a new major release, navigating such disruptive changes fits right in with expectations.
>
> I think the best plan is to continue what has been set up, releasing Tcl 9.0 and Tk 8.7.  All the testing work has already been accomplished to achieve this.  All the infrastructural work to have incompatible Tk 8.7 binary library variants co-exist is already in place.  The missing comfort bits are all in the realm of achieving separate releases, and providing information assuring folks on what to expect.
>
> A second-best plan I think would still be ok would be to release the current trunks as Tcl 9.0 and Tk 9.0.  That implies a major version bump to Tk where there isn't an incompatibility justification to compel it, but that's not forbidden.  Following that alternative plan, there would be no Tk 8.7.
>
> We should not try to release the same Tk sources twice as two differently numbered releases.  They won't be precisely the same sources, because they will differ in a minimal patch changing the release number.  This means they will come from different fossil branches, and once you have multiple branches **they will diverge**.
>
> Summarizing, I think that *if* we aim to decouple the projects, this is the right time to decouple the release numbers, and we need to address whatever discomforts that is stirring up in people.
>
> I think decoupling brings substantial benefits, but if that's an oddball view then best we resolve that foundational matter now and recommit to Tcl/Tk as a forever joint project.  I'm most interested in what answer will best serve those most actively involved with Tk development and expect to defer to their needs and preferences.
>
> DGP
>
>
> On 7/30/23 20:35, Steve Landers wrote:
> > I’ve seen a few recent posts referring to Tcl 9 / Tk 8.7.
> >
> > I propose that Tk version numbers are the same as the Tcl version they are released with (Tcl 8.7 / Tk 8.7 and Tcl 9.0 / Tk 9.0) even if the code is identical.   For multiple reasons:
> >
> > * less confusion, especially if (as proposed by many people) Tcl 9.0 is released before Tcl 8.7 - just say Tcl/Tk 9.0
> > * the shared library will likely be a different file name anyway because of binary changes
> > * we can evolve individual Tk versions separately and at a faster pace than Tcl - for example, Tk 9.0.1 might make use of features only in Tcl 9.0
> >
> > I’m interesting in hearing any counter arguments.
> >
> > -- Steve
> >
> >
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
> --
> | Don Porter Applied and Computational Mathematics Division |
> | don...@ni... Information Technology Laboratory |
> | http://math.nist.gov/~DPorter/ NIST |
> |______________________________________________________________________|
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core