Repository? -- How many lines of development?

[Joseph D. Darcy]

Hi David,

On 11/28/2016 1:47 PM, David Holmes wrote:
> Sorry Joe this got forgotten ...
>
> On 19/11/2016 2:33 AM, joe darcy wrote:
>> Hello,
>>
>> On 11/18/2016 5:50 AM, Aleksey Shipilev wrote:
>>> Hi,
>>>
>>> It is very exciting to see the JDK 10 mailing list!
>>>
>>> When can we expect open forests (or maybe a monorepo that was discussed
>>> at jdk9-dev some time ago [1]) for JDK 10? :)
>>>
>>> Thanks,
>>> -Aleksey
>>>
>>> [1] http://openjdk.java.net/jeps/296
>>
>> And thus will commence the first thread in jdk10-dev, how many lines of
>> development where "line is development" means either a forest or a
>> monorepo.
>>
>> For a few reasons including not holding up the start of JDK 10
>> development for further discussion about and administrative advancement
>> of JEP 296 and to give more time to work on internal-only details of the
>> repo consolidation (such as how the various closed repos are handled),
>> the JDK 10 lines of development won't start out as monorepos. They will
>> at least initially use the existing multi-repo structure as in JDK 9.
>> However, we'll return to JEP 296 later in the release.
>>
>> Regardless of many repos used for a line of the development, there is a
>> larger question of how many lines of development to have. For JDK 10 I
>> propose three lines of development:
>>
>> * A master forest, serving the roles master and dev play today in 9.
>>
>> With a few exceptions, in JDK 9 master was just time-delayed copy of dev
>> so we can implement recording the  information about which set of
>> sources correspond to a promoted build without using a whole other 
>> forest.
>
> I agree with the description, but how does someone get a stable 
> snapshot of master at a given "level"? How will the tagging work?

For the combined dev/master forest, the most recent integration tag will 
have the same stability guarantees we have today so "pull the most 
recent jdk-10+XYZ tag" to get a stable snapshot.

As an aside, for JDK 10 I'd also like to see promoted builds on a more 
frequent schedule than once a week.

>
> I also think the name "master" (due to historical usage) suggests a 
> level of stability that won't actually be present. Maybe it is better 
> to call it "dev"?
>

Much of the stability we see in master today is because the forest only 
changes once a week with the dev -> master integration ;-)

In a nutshell, the proposal is to replace tracking the known-good state 
in 9 via integrate dev -> master, tag in master, pull down to dev 
process today with just "tag known good in combined dev/master" in 10.

Cheers,

-Joe