Date: Thu, 28 Mar 2024 18:35:53 -0400 (EDT)
Message-ID: <697491847.29086.1711665353281@lyrasis1-roc-mp1>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_29085_758233977.1711665353280"
------=_Part_29085_758233977.1711665353280
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
This page gives some notes on how to go about coordinating a DSpace=
release.=20
The Release Team
The release team is selected from volunteers from the Committer Group.&n=
bsp; Each release team selects a "team lead", but all members of the releas=
e team are expected to help with release coordination duties.
DSpace development
DSpace is a community driven open source project. This means that the re=
quirements for new features are driven by the community, and the actual cod=
e developments are contributed by the community. Therefore much of the role=
of the release team is based around working closely with the community to =
ensure that requirements are documented, and code is contributed.
What =
is a Release Team expected to do or not do?
Generally speaking, the release team helps coordinate the next release o=
f DSpace. This may include (not an exhaustive list):
- Help keep code development around a release organized (DSpace JIRA=
is a great resource for keeping organized)=20
- e.g. Ensure each new feature or bug fix has a developer assigned to it<=
/li>
- e.g. If a developer needs help/feedback, help locate that help/feedback=
from the Committers or the community
- Help communicate information about the Release to DSpace Community
- Report on release status updates during DSpace Developer Meetings
- Ask for additional help/support when a release requires it
The Release Team is NOT expected to:
- Make all decisions themselvs (FALSE: The Release Team should u=
se the Committers Group to help make decisions. But, the Release Team can v=
eto an idea, or ask for a re-vote, if it doesn't seem plausible for the rel=
ease.)
- Be an expert on every feature in the release (FALSE: The Relea=
se Team should be aware of who the feature experts are, and be able to dele=
gate questions to them as necessary)
- Do everything themselves (FALSE: The Release Team should deleg=
ate tasks to the Committers Group or others as necessary. In addition, Dura=
Space provides additional support available on request.)
Example Tasks
Listed below are example tasks that a Release Team may need to undertake=
(or delegate to someone else to handle). Some of the tasks may include:
- Determine, along with the development community, whether a major or min=
or release is required. Minor releases include bug fixes and minor, non-db-=
schema-altering changes; mostly minor releases can be installed by replacin=
g the DSpace code. Major releases include major functional enhancements, co=
nfiguration changes and db schema alterations.
- Determine, along with the committer group, the requirements for the nex=
t release. If it is a minor release, this may be as simple as fixing any bu=
gs that have been reported in JIRA. For a major release, you will likely wa=
nt to consult the community via surveys, emails, or JIRA voting to determin=
e what features should be included. Final determination is often done in co=
njunction with the rest of the committers.
- Work with the development community and committer group to find volunte=
ers to develop new features.
- Work with the committer group to find volunteers to claim PRs, code rev=
iew / test them, and merge into the codebase
- Determine a feature freeze date. In a normal release cycle, there will =
hopefully be a constant influx of patches waiting to be rolled into the rel=
evant release. The feature freeze date, therefore, need not be a long way i=
n advance. It's useful if the date is a Friday, as this allows trailing tim=
e-zones to catch up before work in earnest can start on code integration on=
the Monday.
- Announce to dspace-devel, dspace-tech and dspace-general lists the date=
of the feature freeze for the coming release, requesting patches and bug f=
ixes.
- The job of the release team is not to test all the patches and fix all =
the bugs, but to help others in doing so. Advise the list of any important =
events in development and liaise with patch authors to ensure smooth develo=
pment.
- Once the freeze date has occurred, hold a Testathon. Encourage the community to take part in the testathon=
to make the release less buggy. Ask for volunteers to run test instances o=
f the new version to allow people who do not have access to a server to be =
able to test it.
- Following the testathon, the release may be ready, or it may have signi=
ficant bugs, in which case bug fixing is required, and another release cand=
idate. Work with the community to find volunteers to fix bugs.
- The release team is responsible for building the release package and up=
loading it to SourceForge. See Release Procedure for information on how to do this. The release team=
should also email dspace-devel, dspace-tech and dspace-general to announce=
the release.
Things t=
o Do at the Start of a Release Cycle
- Review prerequisite software (DBMS, Java, etc.) version requirements wi=
th the developer community, and adjust them as required. Keep the doc=
umentation of this up-to-date.
- Review dependency (e.g. log4j) version requirements and adjust as requi=
red. Tools such as
mvn dependency:analyze
can help. =
; Also remember non-Java things such as Javascript libraries. This co=
uld be a big job, so ask for volunteers to help.
In general, try to establish a stable up-to-date foundation for developm=
ent and integration early on.
Tips
- It is never too early to start thinking about the release.
- It is never too early to start talking about the release. People are bu=
sy and need reminding.
- Try and create a provisional list of major features as soon as possible=
, even though it will undoubtedly change throughout the year.
- Engage with the developers and gently push for development and commit t=
imescales. Just talking may help speed the process.
- A commit date for a major feature of one week before the feature freeze=
is too late, it will inevitably result in a postponement of the feature fr=
eeze date. All code needs review and probably rework, developers need to re=
cognise that and plan accordingly.
- Don't be afraid to badger people. It goes with the role and people expe=
ct it.
- Don't be afraid to ask for help.
------=_Part_29085_758233977.1711665353280--