-
Notifications
You must be signed in to change notification settings - Fork 132
The release process
Work in progress. Please contribute
This page is build as a reminder/to-do list on what should be done to dreate a new "Sloeber".
The steps to make a new release as follows:
- Update the version numbers in the manifest, xml and pom files
- run the unit releaseTesting_takes_very_long.java
- try a upgrade from a previous stable release
- Update the sloeber.io web site
- Make a release in github
- update the stable update site on sloeber.it
- Share with the world.
Lets go into detail for each of these steps:
In eclipse update for all project the pom.xml file
For the pojo projects update the manifest.MF file
For the feature projects update the feature.xml file
For the product projects update arduino.product
If all of this has been done correctly mvn verify should run ok and the build product should reference the new version numbers.
If so check-in the changes and push to github.
By cheking in before running the unit tests the test can be run on several systems and os'es at the same time.
The test script releaseTesting_takes_very_long.java runs all the release testing except for upload as this is dependent on available hardware.
Note that not all tests are successful. For instance in V4.2 testing about 400+ boards succeeded the build default ino in V4.3 that is 500+
Some tests stop after a number of failures. so check the total number of successful tests
Running the tests is faster when running (in contrast to debugging) but if you need to download all boards and run all tests don't expect stuff to finish in less than 24 hours
Note that the whole test setup is still pretty new and buggy. so test validation should be taken seriously.
Try to run a upload test. Uploading has proven to be a sensitive matter so try to upload to as many boards as possible.
Make a new release X_Z on github. (do this before you updated the web site and after a successfully maven build with all changes checked in (FI locally or on jantjes build server) so the updated site is tagged correctly.
From the build location: Copy the build product files (3 in total) to the github release.
If the files come from jantjes build server the java jre folders is added to the windows release.
On github rename the issue label "status: fixed in nightly" to "status:fixed in release X.Y" and create a new label "status: fixed in nightly"
Of course you need the right credentials to do so.
eclipse.baeyens.it is updated via the github repository and the nightly build on Jantjes Build server.
In general this is a good time to check if everything is still "acceptable" on the website.
But for sure:
Update the globals.txt file to reflect the new version number.
Update the index.shtml page to share the good news.
Add the newly released files to fragments/files.php
Update the fragments/navbar.html to contain a extra archived version
Check nightly.php and stable.php to work correctly.
push your changes to github.
Prerequisites
- Jantjes build server workspace is accessible as file system
- You have read and write permissions to the workspace
Step 1
Download the VX folder from ftp.baeyens.it/eclipse/update/VX/stable
Start your sloeber development environment (pde not cdt)
open the workspace on the build server
right click on the io.sloeber.updatesite and select export
select plug-in development->deployable features->next in available features select io.sloeber.feature
in destination select the downloaded Vx folder
in options make sure the source is not selected and "use class files compiled in the workspace" is selected
select finish
wait until done On baeyens.it rename the VX update site for backup reasons upload the VX folder to ftp.baeyens.it/eclipse/update/VX/stable
Updating the eclipse market place is also a good idea. As we are at it. Do both the product and the plugin version. Be extra careful to tag the compatible eclipse versions It is also a good idea to tweet about the new release.