Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Remove design-docs folder

This has turned into a graveyard for ideas. It only serves

to confuse people at this point. We have found it more productive

to either

- use GitHub Epics and issues for smaller design questions

- use Google Docs for larger topics (e.g. native publishing)

These documents quickly go out of date once a feature is implemented.

They are not a replacement for good user and code documentation.

Many of the documents are about features that we never ended up

implementing. Having those documents still around might lock us

into a certain way of thinking about a problem. Instead we should

have a fresh look at it when we actually want to start working on it.

  1. … 200 more files in changeset.
Remove some some duplicated words from gradle

  1. … 20 more files in changeset.
Fix parameter

Add open issues

Add estimates

Polishing of spec

Shouldn't sit in internal package

Explain current behavior by code example

Indicate the schema version evolves with features added

The Gradle version is only defined in the build platform meta-data

Documentation and samples should be part of the implementation

JSON also provides a schema version so that it can be validated and evolved over time

Align DSL example

Use a builder object to define build platform GAV

Use consistent terminology

Remove last instance of referring to a JAR file

Milestone 3 is partially required to get rid of Gradle custom distribution

Define milestones with a user-centric approach

- Which problems does it solve?

- How do I use it as the end user?

- How does help me get rid of a custom Gradle distribution?

Clarify scope of work

No need to bundle meta-data into JAR file

tweak stories for "build platform"

More details on build-system-dev plugin

Fleshed out stories for build platform and grouped by milestones

Initial break down of stories for "build environment"