- Deliver v1.2
- Wrap up v1.2
- Do an informal demo of v1.2 before the tutorial
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 release 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 module, and it is not expected to affect your tP grade either.
1 Deliver v1.2
- The product must be working although the functionality is basic.
2 Wrap up v1.2
- Manage the milestone v1.2 as explained in the panel below.
- Wrap up the milestone using a git tag
v1.2. 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 milestone may not finish in time, you can reassign them to a future milestone, provided they are not essential for thev1.2(i.e., the you can still get a 'working product' without them).
- Do a release on GitHub. Uploading a JAR file to GitHub is optional.
3 Do an informal demo of v1.2 before the tutorial
- [one member] Run your app using the latest released version
v1.2(orv1.2b, if applicable). Take screenshots of each available feature in action. Add those screenshots to your project notes document with an appropriate heading e.g.,v1.2 features demo. Alternatively, you can screen-record a demo, upload it to somewhere, and post the link in the project notes document.