[Cuis] Managing the evolution of Cuis (Public APIs, checking them and Releases)

[H. Hirzel]

On 7/23/15, Juan Vuletich <juan at jvuletich.org> wrote:

Thanks for this summary, I think it captures what we have discussed.

Two comments below

--Hannes

> Hi Folks,
>
> I've just re-read the very rich threads related to this. Thank you all
> for thoughtful and valuable considerations and opinions. This mail
> attempts to make really small summary, to start taking action.
>
> First, the easiest. Releases
> -------------------------------------
> Several of you see real value on doing a few named releases per year.
> Theres' no big downside, so, let's do it. I think this is a good time to
> do a release. So, I'll refrain to introduce any major changes, except
> important bugfixes. Please start testing / updating / fixing your
> packages and applications. When we are all happy, and we all agree that
> the whole ecosystem is in a healthy state, we'll call that a release.
>
> We need a name for this release. The obvious choice is "Cuis4.3-nnnn".
> So, there might be a Cuis4.3-2456, and as that branch evolves, a
> Cuis4.3-2457 and Cuis4.3-2458. Shortly after, we'll be doing the "alpha"
> updates of Cuis4.4. So, I guess #2459 would be (a potential risky
> change) for Cuis 4.4. What if later we need to apply some patch to the
> stable Cuis4.3? How would we name it?
>
> After a bit of discussion, I can take action. Or you can volunteer for
> Release Manager or member of the Release Team for Cuis 4.3.

A suggestion: label the version of tomorrow as Cuis 4.3

and then have a period (4...8 weeks?) where only bug fixes are allowed
and then release a version Cuis 4.4


Cuis 4.3 would then be what KenD calls a 'baseline' to measure against
until we have 4.4

>
> Next, Documented, Public APIs
> -------------------------------------------
>
> Use pragmas, like PubicAPI (some method we intend to support and keep in
> that hierarchy), or CalledFromOutside (some method our yet-to-be-written
> tool detects as called from another package). Write tools for analyzing
> them. Do not remove them without due discussion.
>
> It should be possible to write tests for existence of APIs.
>
> This area is new to us, and we'll learn as we go.
>
> Anybody can take action here. Documenting APIs by hand, writing tools to
> try to autogenerate them, writing tests that check for existence of
> specific APIs, whatever you can come up with.
>
> This sounds like a major strategic direction, and in a very early stage,
> so maybe we'd not include anything of this in the Cuis4.3 release, but
> make this the start of the Cuis4.4 effort.
>
> Thoughts? Or feel free to start coding!

I think we should start coding with FeatureTests which check for the
presence of classes and methods.

As independent packages in various repositories, after some
evaluation/testing/checking they should go to the packages folder.

> Cheers,
> Juan Vuletich
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>