Skip to content
This repository has been archived by the owner on Apr 21, 2018. It is now read-only.

Commit

Permalink
Bump components to releases on Fiji update site
Browse files Browse the repository at this point in the history 
The following component versions are present on the update site:
* TrackMate_ 2.7.1
* Trainable_Segmentation 2.1.8

Hence, these should also be the versions declared in pom-fiji.

See: fiji/fiji#37
  • Loading branch information
@ctrueden
ctrueden committed Feb 3, 2015
1 parent 0d5d367 commit 820c172
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions pom.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -217,8 +217,8 @@ Projects wishing to use pom-fiji as a parent project need to override the <na
<Time_Stamper.version>2.0.0</Time_Stamper.version>
<ToAST.version>25.0.1</ToAST.version>
<TopoJ.version>2.0.0</TopoJ.version>
<TrackMate.version>2.7.0</TrackMate.version>
<Trainable_Segmentation.version>2.1.6</Trainable_Segmentation.version>
<TrackMate.version>2.7.1</TrackMate.version>
<Trainable_Segmentation.version>2.1.8</Trainable_Segmentation.version>
<TransformJ.version>2.8.2</TransformJ.version>
<TurboReg.version>2.0.0</TurboReg.version>
<UnwarpJ.version>2.0.0</UnwarpJ.version>
Expand Down

5 comments on commit 820c172

@hinerm
Copy link
Member

@hinerm hinerm commented on 820c172 Feb 6, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this TrackMate version was not actually deployed to Maven, which made this pom invalid. Fixed for now but makes me feel like we do need to enforce standardized release processes.

@ctrueden
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The question is: how often will we have to fix this stuff, versus how much time will it take to improve the tooling even further and then educate Fiji plugin authors about the new release process?

While I agree with you 100%, my current feeling is that we should hold off on any further tooling work for at least the first half of this year.

@ctrueden
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, the people doing the releases are @tinevez and @StephanPreibisch. Also @iarganda is active doing releases. For now, it would be faster to just educate them (hi guys!) on our desired release process, than to do the eventual tooling work we want to have.

@tinevez
Copy link
Member

@tinevez tinevez commented on 820c172 Feb 6, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood!
I guess the decoupling between Fiji and its flock of plugin as I pictured it was too perfect to be functional.(Though, did you notice we are perfectly able to work in a relatively unsynchronized manner? It's a tribute to the work done in the past 2 years)

My understanding of the plugin release process is the following:

  • commit a non-SNAPSHOT version;
  • tag it;
  • push it;
  • upload the compiled artifact to the Fiji core repository;
  • and if I get it correctly, pull pom-fiji. update the corresponding fiji version tag, commit and push it.

Right? Did I miss something? Are some steps non mandatory?

@ctrueden
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tinevez For the moment, the recommended workflow is as follows:

  1. Update your pom.xml to the desired release version (e.g., change 4.5.6-SNAPSHOT to 4.5.6).
  2. Build it locally and make sure it works!
  3. Commit and push to master.
  4. Wait for Jenkins to build it. The result will be deployed to the ImageJ Maven repository for you, making it available as a dependency for other projects.
  5. Update your pom.xml again to the next SNAPSHOT version (e.g., change 4.5.6 to 4.5.7-SNAPSHOT). Commit and push to master.
  6. Download the deployed release JAR file from the ImageJ Maven repository, copy it into your local Fiji installation and use the Updater to upload it to the Fiji update site.

I sometimes refer to this as the "double-push to master" release process.

Other actions are optional; e.g.:

  • Create and push a tag for the release.
  • Change pom-fiji to reference the newly released version.

In particular, you guys will rarely need to worry about the pom-fiji updates for the time being.

The reason I say this is the process "for the moment" is that we have in mind an improved process, which we hope to implement later this year: make Jenkins always automatically upload the state of https://github.com/fiji/fiji master branch to the Fiji update site. Once we do this, there will be no more need to ever manually upload something to the update site, because it will be kept in sync with the source repository. At the moment, there is still skew; see fiji/fiji#39 and fiji/fiji#37.

We will probably also eventually want to move away from the double-push-to-master release process in favor of using the Maven release plugin, via our release-version.sh script. This script is better because it performs additional important actions—in particular, it sets the <tag> properly in the POM file, and does the release commit as an orphaned tag off the master branch.

Please sign in to comment.