Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • O org.eclipse.dash.handbook
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 156
    • Issues 156
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1
    • Merge requests 1
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Eclipse ProjectsEclipse Projects
  • Technology
  • Eclipse Dash
  • org.eclipse.dash.handbook
  • Issues
  • #128
Closed
Open
Issue created Feb 08, 2019 by Eclipse Webmaster@webmasterOwner

Add advice regarding releasing parts of a project

Submitted by Wayne Beaton @wbeaton

Link to original bug (#544297)

Description

It's relatively rare, but some projects need to release parts of their project. Projects that make a habit of this sort of behaviour should probably consider refactoring (i.e. if you're releasing components on different schedules, should those components be separate projects?).

Here's part of an email that I sent to a committer.

To do a formal release, you need to first create a release record. You can put arbitrary text into the release name, so you could, for example, call a release "glassfish-doc-plugin 1.0" and then engage in the release process with that. The only real challenge in this is to ensure that it doesn't confuse the community or the development team.

Note that we made a change to the EDP in December that lets a project push out releases for a year after engaging in a successful Release or Progress Review. So you don't actually need to submit an IP Log for review or engage in a Release Review. Just create the release record and push out your bits. Any IP reviews associated with the content that you're pushing out need to be fully resolved before you push out anything that is considered an official release.

FWIW, you can also just build and push the new content to Maven labeled as a "milestone" build (or "alpha", "beta", "SNAPSHOT", whatever) of the forthcoming Eclipse GlassFish 5.2 release (e.g. set the version of the Maven record to "5.2M1" or something).

From a process point-of-view, you could also create an "Eclipse GlassFish 5.1.1" release that includes all of the exact same versions of software Eclipse GlassFish 5.1 has plus this plug-in. There's no rule that says that you have to rebuild everything, or that every software component share the same version as the associated Eclipse Project release (for example, the Eclipse IDE project only builds new versions of their plug-ins that actually change; "Eclipse IDE 4.10" includes plug-ins with a very wide range of version numbers). Again, it's really all about managing community confusion.

Eclipse MicroProfile also does this, so there might be an opportunity to scavenge some text from email exchanges with that team.

--

Assignee
Assign to
Time tracking

Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent