Ticket #401 (closed Task: worksforme)
run nightly snapshots and stable releases in parallel on demo server
Reported by: | JuergeN | Owned by: | jri |
---|---|---|---|
Priority: | Major | Milestone: | |
Component: | Demo server (demo.deepamehta.de) | Version: | 4.0.13 |
Keywords: | Cc: | dgf | |
Complexity: | 3 | Area: | |
Module: |
Description
I want to run and test both the up-to-date nightly snapshots and the stable releases on the demo server. My solution is to run various instances of deepamehta on different ports on demo.deepamehta.de, e.g.:
demo.deepamehta.de:8080/de.deepamehta.webclient for the latest released version and
demo.deepamehta.de:8082/de.deepamehta.webclient for the nightly builds.
It would even be much nicer if we could prefix the versions in the URLs
demo.deepamehta.de:8080/released/de.deepamehta.webclient for the latest released version and
demo.deepamehta.de:8082/snapshot/de.deepamehta.webclient for the nightly builds.
I will work on this and add a comment and a link to these different versions on the home page of demo.deepamehta.de once they are in place.
I.m.o. we should switch to the next release+1-SNAPSHOT quite immediately after the release.
Change History
comment:2 follow-up: ↓ 6 Changed 12 years ago by jri
Im still hestitant to merge into master now.
- We must reset the DB.
- Retyping and thus building of composite types will not work.
Do we want this anyway?
comment:3 Changed 12 years ago by jri
I'm curious about the demo page and there is one error: why do we set the port number of the 2 livedemo links dynamically via Javascript? This way the port number do not appear in the browser's status bar (on mouse over) which might be confusing as the user thinks (when looking at the status bar) that both links lead a to the same livedemo.
1) To straighten things out, if there is no good reason for using Javascript here, the Javascript should be dropped (and the port number added to the URL instead).
2) The Javascript is invalid: the javascript: protocol prefix must be dropped. It is only used in URLs (in the "href" attribute), but never in an event handler (here: "onclick" attribute).
comment:4 Changed 12 years ago by jri
Thank you, JuergeN, for setting up the 2 separate live demo instances!
They will be beneficial soon.
comment:5 follow-up: ↓ 8 Changed 12 years ago by JuergeN
1) To straighten things out, if there is no good reason for using Javascript here,
the Javascript should be dropped (and the port number added to the URL instead).
I agree, but for some reason it did not work the easy way. I won't spend more time into this (took me more than an hour to find this sollution) for now unless you/someone suggests a working and tested alternative.
2) The Javascript is invalid: the javascript: protocol prefix must be dropped.
It is only used in URLs (in the "href" attribute), but never in an event handler (here: "onclick"
attribute).
see my comments on 1)
comment:6 in reply to: ↑ 2 ; follow-up: ↓ 7 Changed 12 years ago by JuergeN
Replying to jri:
Im still hestitant to merge into master now.
- We must reset the DB.
The Demo-DB is completely useless until now and it will be until we have a stable DB.
Right now it is broken anyways. So we can just givea shit about it.
- Retyping and thus building of composite types will not work.
Never mind. It is a testing environment! If you know it already, you can also just create a first ticket for it. That's all what we should care about.
Do we want this anyway?
YES. We want the next SNAPSHOT release immediately after the release, so that we can start testing it. (We need to get faster in so many ways and this delay is slowing things down again. ... AND AGAIN ... AND AGAIN!) It also stops my motivation at some point. So please act!
comment:7 in reply to: ↑ 6 ; follow-up: ↓ 9 Changed 12 years ago by jri
Replying to JuergeN:
YES. We want the next SNAPSHOT release immediately after the release, so that we can start testing it.
Sorry, JuergeN, I don't want bother you.
I should have explained it better: merging into master affects not only the demo server but EVERYONE who builds from source. Everyone who builds from source will make the experience that a central DM feature -- building types -- is not working.
To avoid that we have one principle: the master branch is functional AT ANY TIME. A feature branch is merged into master as soon as the feature is functional.
I fully agree that new functionality or fixes should be provided as a SNAPSHOT release as soon as they are available. That is our praxis of the recent months and years. From my point of view this is best practice.
Regarding the current situation: since 4.0.13 there is NO snapshot release yet.
Everyone who want to test the current development version can checkout the "assoc-index" branch.
I really don't want slow things down. Rewriting the entire storage layer just takes 2-4 weeks. There is no way around it. And it's almost done. I just need 2 or 4 days more. Next week we should be ready for merging.
The simple solution that should solve our little misunderstanding: in Jenkins set the branch for the nightly demo server build to "assoc-index" (instead of "master"). Advantages would be:
- Everyone who builds from master always gets a functional version
- The nightly build demo server has the on-the-edge developer version
- We can retain our powerfull branching/merging strategy
Please excuse my bad communication.
comment:8 in reply to: ↑ 5 ; follow-up: ↓ 10 Changed 12 years ago by jri
Replying to JuergeN:
I agree, but for some reason it did not work the easy way. I won't spend more time into this (took me more than an hour to find this sollution) for now unless you/someone suggests a working and tested alternative.
OK. Now I see what your intention might have been: using an absolute URL (starting with /) without stating protocol and host.
I've put in full URLs now and dropped the Javascript. Is this OK for you?
comment:9 in reply to: ↑ 7 Changed 12 years ago by JuergeN
Replying to jri:
The simple solution that should solve our little misunderstanding: in Jenkins set the branch for the nightly demo server build to "assoc-index" (instead of "master"). Advantages would be:
- Everyone who builds from master always gets a functional version
- The nightly build demo server has the on-the-edge developer version
- We can retain our powerfull branching/merging strategy
OK. JENKINS: switched branch to assoc-index.
comment:10 in reply to: ↑ 8 Changed 12 years ago by JuergeN
Replying to jri:
I've put in full URLs now and dropped the Javascript. Is this OK for you?
After Silke has added a simple style sheet, the site looks better now. It's the little enhancements ... ;-)
comment:11 Changed 12 years ago by JuergeN
- Status changed from new to closed
- Resolution set to worksforme
Step 1 is done:
http://demo.deepamehta.de now provides both, the latest release and the snapshot (nightly build). So from my point of view it's time to move the master to snapshot now.