On Fri, Jun 22, 2012 at 11:14 PM, Barrie Treloar
<baerrach@xxxxxxxxx> wrote:
On Sat, Jun 23, 2012 at 4:58 AM, Johannes Serup <johs.serup@xxxxxxxxx> wrote:
[del]
> c) There is no distrubtion system. So there is no way of depending on
> previously build binaries. To my understanding even nexus pro does not have
> full support for osgi/p2 repositories that can be integrated with maven SCM
> and the maven-deploy-plugin.
So you are supplying your users with you app already bundled, e.g. as
a zip file.
Yes
What happens in a months time when bugs are reported?
Assume that a user has filed a bug report using myApp-1.0.0.zip. Then I would do:
1) Create a bugfix-branch from tag/myApp-1.0.0
2) Fix the bug on the bugfix-branch
3) Create the new tag/myApp-1.0.1 from the bugfix-branch.
4) Build from tag/myApp-1.0.1 and ship the updated zip to the user.
Do you give them another zip that contains the same named artefacts?
See 4)
What about in a further months time when more bugs are reported?
Same steps as above.
How will you tell which versions they were using?
The version of the tag is included in the branding of the application.
How will you be able to reproduce the problem on your desktop with the
same install base and compare that against the code?
Not sure I understand. I can reproduce with a build of the corresponding tag and the neceesary steps to reproduce from the bug report.
The standard best practice is whenever you give something to someone
outside of your dev team you want released versions that never change.
Yes never commit on a tag after it has been created. But if you checkout the tag and build it the jars will have new timestamps but the source is unchanged as well as the branding version which corresponds to the tag version.
I am aware that this is definitely not recommended practice but from a pragmatic point of view I don't see any problems assuming a) -d).
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user
