Re: [Jython-dev] Maintaining the Definitive Guide to Jython

[Jeff A. <ja...@fa...>]

In discussion on PR 4 (https://github.com/jython/book/pull/4), Adam 
suggested we version-tag so that we know where we are in relation (in 
particular) to the paper version. Good idea, worth elaborating here. All 
sound sensible?

I propose to use roughly the scheme we use for Jython (and CPython), but 
with "Ed" (edition) rather than "v" (version). I don't currently see a 
need for the "micro" number.

Let's assign:

Ed0.9 for when Josh wrote v0.9 in index.rst.

Ed1.0 for when Jim finished Chapter 19. (This seems to be the copy that 
became Apress' Ed 1.)

Ed1.1 when we've shaken the bugs out of the build (and write that in 
index.rst).

I further propose we create a branch according to the version of Jython 
being described. I imagine that if we write anything new we will 
describe 2.7 behaviour, but that we'd like to preserve (and bug-fix) the 
v2.5 version as a coherent work. The v2.5 branch starts at Ed1.1, and 
thereafter the master branch will describe Jython v2.7. Using "Ed" and 
"v" in this way lets us speak slopply without confusion.

The draft Ed 2 will inevitably contain a mixture of v2.5 and v2.7 
material for some time, no matter how enthusiastically we work on it. 
I'm not assuming anything, just preparing. RTD supports publication from 
more than one branch so readers have a choice between consistency and 
the latest writing. I think we can publish from a tag too.

We face the same conundrum we face moving on after a software release, 
where we want to say "this is version X.Y but we haven't finished yet", 
for which we often use a suffix "X.Y-something", so maybe the first 
commit on the v2.7 branch should announce (in index.rst) as Edition 2 
(draft) and Ed2.0-draft if we tag it.

Jeff Allen

On 06/05/2019 18:44, Jim Baker wrote:
> Jeff,
>
> Thanks for bringing this up! It would be great for this book to be 
> updated with PRs, which is why we licensed it under CC-SA, wrote it 
> using a source text approach, and placed it under repo management.
>
> We also currently have assent support for any PRs per GitHub terms of 
> service:
> https://help.github.com/en/articles/github-terms-of-service#6-contributions-under-repository-license
>
> (See more here: 
> https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/)
>
> So really there's nothing more to be done on the admin side, as I see it.
>
> - Jim
>
> On Sun, May 5, 2019 at 9:14 AM Jeff Allen <ja...@fa... 
> <mailto:ja...@fa...>> wrote:
>
>     We have a few pull requests against the Jython book in GitHub, and
>     some interest in seeing it updated. The authors hold a copyright,
>     but released it under a Creative Commons 3.0 CC-BY-SA Licence. It
>     publishes automatically via ReadTheDocs. https://jython.readthedocs.io
>
>     One clear thing is that a modified version must also be released
>     under the same license. Contributors have to assent to that
>     somehow, and this has nothing to do with the license under which
>     the Jython code base is released, or the PSF contributor form. I'm
>     wondering what that assent consists of, and how we keep a record.
>
>     I found this helpful:
>     https://wiki.creativecommons.org/wiki/Best_practices_for_attribution
>     in forming an idea of what the intention is.
>
>     The stuff about re-use and derivative works does not perfectly fit
>     the case of publication from a repository, but I think closely
>     enough if one regards the state handed down as an "original" and
>     any current state as either "modified slightly" (after a simple
>     bug-fix) or a "derivative" (after adding a new chapter). The
>     record of change in the repository will do, I think, as a
>     description of who authored what change. Almost everything asked
>     for by CC as attribution is supplied by the context, given the
>     change is *in* the repository.
>
>     I've seen it suggested each commit/patch should contain a label
>     signifying assent. Elsewhere I've seen a requirement to add
>     oneself to a contributors file, in which could assert the license
>     at the top. It's hardly unforgeable, but evidence of a sort if
>     need be, which it probably never will. Does either of these seem
>     reasonable to us to ask people? Thoughts?
>
>     Jeff
>
>     -- 
>     Jeff Allen
>