- Moderator: <moderator's login name>
- Protocol: cds
- Start: 14:15h
- End: 15:40h
Leftover ToDos from Last Meeting
- The KEG editor actually does depend on the Pragmatics component. The graphic thus doesn't need to be changed.
- We like the idea of splitting the product into different components and repositories. In particular, the split we discussed in the previous meeting seems reasonable.
- Miro isn't too fond of the idea of releasing the General component separately.
- The solution is to release the General component together with the other, major components. Thus, not as a separate component.
- Developers in repository 3 develop against the latest release of repository 2, not the current source code. Repository 3 would release a month after repository 2 has released.
- Both repositories release the then-current state of General implicitly.
- Release repository 2 in odd months, repository 3 in even months. If nothing much has happened, don't release.
- How does plug-in version management scale with an increased number of releases?
- API tooling could be used. Miro found it to be slow and instable, however.
- Miro thinks that with smaller components, manual version management would be feasible even with a two-month release cycle.
- Tim thinks that developers responsible for a component can choose how they manage versions for themselves.
- The General component might be a special case:
- Versions must be changed instantaneously. As soon as someone changes stuff that justifies a version change, he must change the version immediately.
- Management tools:
- Confluence would keep a single space for the whole project.
- Jira would get three different projects.
- FishEye would have one project with three different repositories.
- Bamboo would have two or three different projects. (repository 2, repository 3, complete RCA?)
- Repository 2 could be built nightly.
- Repository 3 could be built nightly against the most recent build tag of repository 2.
- An RCA nightly build might not work. We might only be able to release a new RCA each time Repository 3 releases. That would be OK, since Repository 3 contains most of the demonstrator projects anyway.
- Project split:
- Miro strongly suggests getting rid of repository 1 altogether. The General component would be distributed to Repository 2 and Repository 3.
- A problem would be what to make of core.ui.
- Actually, Repository 3 would have to contain the Pragmatics component as well since it changes a lot and Repository 3 components depend on it. If that's the case, we're not sure if there are any advantages left of splitting the project in the first place.
- Three options:
- Don't split at all.
- Split into Layout and Everything Else.
- Go with the three-repository split.
Pros and Cons with Respect to Our Goals
We formulated our goals during the previous meeting. In this section, we discuss pros and cons.
Easier Development for Students
- Contra: It might actually become more complicated for students (and developers in general) that are active in more than one repository.
Easier for Third Parties
- Pro: Splitting the Layout component from the rest would make it easier for the rest of the world to use it.
- Pro: Easier releases because of smaller releases.
- Pro: No blocking between two different parts of the project.
- Pro: More releases!
- Pro: Less political delaying of releases: if the next release is only two months away, moving a feature to the next release doesn't hurt all that much.
What We Have to Do
- Miro prepares a proposal for splitting the project into Layout and Everything Else.
- We'll hold another meeting on what to do about Repository 3.