- Manage the iteration, and deliver v1.2 Thu, Mar 21st 23:59
- Start updating UML diagrams in the DG
How to define version numbers?
While there is no universal set of rules on choosing version numbers for a product, there is a convention named SemVer that is well-defined and widely used. Our tP version numbers (v1.2, v1.3, v1.4 etc.) do not follow SemVer strictly though.
While on the topic of version numbers, milestones and versions are not the same thing. For example, you can have a version released in the middle of a milestone, and you can define a milestone that does not release a new version of the product. For convenience, the tP uses them interchangeably (e.g., v1.2 is used to mean a version as well as a milestone) because its major milestones coincide with its version releases.
In a similar vein, we use the version number to refer to the iteration as well, although they are not the same thing. So, when we say iteration v1.2, we mean the iteration that ends in the milestone v1.2 (that also happens to deliver the product version v1.2)
Using parallel PRs yet? We encourage you to try sending parallel PRs (i.e., send another PR while the previous PR you sent is waiting to be merged) if you haven't done that yet. Reason: It's important to learn how to do that, because in most real projects it is common to have multiple open PRs from the same author.
Shocked by iP to tP transition? Around this time you will realize how the speed you can implement things in the tP is significantly slower compared to the iP. As discouraging as this might feel, there are several ways this can contribute towards the learning outcomes of this course, and it is not expected to affect your tP grade either.
1 Manage the iteration, and deliver v1.2 Thu, Mar 21st 23:59
Note that the product you deliver at the end of this iteration must be working although the functionality is basic.
- Manage the iteration
v1.2, and reach the milestonev1.2(which delivers product versionv1.2) as explained in the panel below.
Wrap up the iteration/milestone. When the milestone deadline is near (e.g., 0.5 days before the deadline), if you think some of the ongoing work intended for the current iteration may not finish in time, you can reassign them to a future iteration, provided they are not essential for the
v1.2(i.e., you can still get a 'working product' without them).Do a release on GitHub, when the product
v1.2is ready. Requirements:- Write a fairly detailed Release Note in the text field GitHub provides for the description of the release. In particular, describe what has been changed (compared to AB3). This is just an itemized list of What's New -- no need to be as elaborate as a user guide.
Include screenshots (or screen recordings) of your product in action, featuring the changes you've done.
These release notes will be checked by the teaching team to verify (a) that they are written reasonably well, and, (b) that the features mentioned in there show the product has reached the MVP level of functionality. - Upload the JAR file as well.
- Write a fairly detailed Release Note in the text field GitHub provides for the description of the release. In particular, describe what has been changed (compared to AB3). This is just an itemized list of What's New -- no need to be as elaborate as a user guide.
2 Start updating UML diagrams in the DG
This is a good time to get familiar with the diagramming tools used by the tP.
- Each member is expected to update at least one UML diagram in the DG, to match the changes you've done in
v1.2. You may do this towards the end ofv1.2, or soon after you finish it. - Updating the DG text to match the diagrams is optional (it can be done in
v1.3). - FYI, the panel below has some DG tips, some of which are related to drawing diagrams.