revive-adserver / revive-adserver

The world's most popular free, open source ad serving system. You can download the latest release at:
http://www.revive-adserver.com/download/
GNU General Public License v2.0
1.24k stars 562 forks source link

Instructions on how to create release packages #154

Open skynet opened 10 years ago

skynet commented 10 years ago

Can anyone provide some instructions or build notes on how to create the release packages, in order to be able to use the development version for testing. Thank you.

mbeccati commented 10 years ago

I'd suggest using the latest daily builds from the continuous integration server. Just go to https://revive.beccati.com/bamboo/browse/REV-DAILY/latest then Artifacts, Packages and download your preferred format. The only thing you'd need to do then is to edit constants.php and put something like 3.0.1-dev as version.

skynet commented 10 years ago

Thank you, Matteo!

But how do I package my own source (a clone of Revive, here on github)? Thanks again.

andrewatfornax commented 10 years ago

The answer actually is that you probably can't, because there is some currently non open source code that is required to run the ant script to package a release. I'd like to see us move away from this (or at least make this possible), but it's not an immediately high priority for the team. Hope that helps!

skynet commented 10 years ago

Apologies for the delay. Please let me get back to this.

Others can also run the non open source script code. You just need to provide instructions on how to gather the pieces and run the packager. Is that something that OpenX sold to Revive when you acquired the code? If that's the case why don't you open source it or write a new version, for the community, at large.

I somehow get the impression that Revive is kept under tight control as much as the previous owner (OpenX) did with the platform. To the point where developers were begging for updates (while they kept updating and selling the Enterprise).

Back to it - what I'd (and with me other developers) like to do is to clone the repo, play with it and re-package it myself. At that point I will send a pull request and you may consider my contribution. Workflow is flawed if you expect me to send contributions w/o being able to test them myself, in my own dev environment.

andrewatfornax commented 10 years ago

Hi @skynet , thanks for coming back on this one.

Sorry if closing the ticket caused confusion - I don't think it was really our intention to say that we weren't going to do anything about this, although I can see that the way the ticket was resolved suggested that - I have re-opened the ticket now.

When it was closed, I was probably thinking about the fact that issue #86 exists, to replace the non-open source packaging code with a re-write in phing. For legal reasons, I can't go into details, but I am not in a position to release the non-open source packaging code, so the only option is to create a completely new solution from scratch - which is what #86 is about.

In the mean time, unfortunately, providing instructions therefore won't help - we need to do the coding before that will help. In addition, as I hope you can imagine, the documentation priorities are around user documentation and administration documentation first, as that's what most Revive users need, and developer documentation is probably last on the list.

I hope that this clears things up - I certainly have no desire to see Revive kept under any more degree of control that a good open source project should be - we want to make sure any PRs that are submitted are good quality and do the job effectively and safely, as best we can, and we want to make sure that any changes make sense to the overall direction of the project (so that means we might reject some features that we feel will make the product worse, rather than better).

Please note, you can definitely test code changes for a PR without having to package the code up! That's how I develop - I simply checkout the code and edit it, and run from the checkout. The only thing this doesn't work for is plugins, which do need to be repackaged - but there is a shell script for this in the plugin_repo directory. Creating a release package of Revive Adserver isn't required for development.

I hope this answers your questions, and if you want to help out with the work on #86 to move it forward faster, we'd really appreciate that!

alenhelac commented 10 years ago

Hi everyone,

First of all, thank you for your contribution to the open source community.

I understand that rewriting packaging code is not a priority at this stage, but it'd be really great if you could tell us what packaging process actually does. Will it only remove dev files, maybe trigger few scripts? Will there be any performance/security issues if I deploy unpacked GitHub source to the production?

Many thanks, Alen

mbeccati commented 10 years ago

Also, see here: http://forum.revive-adserver.com/topic/808-packaging-development-source/?hl=package#entry1916

skynet commented 10 years ago

Thanks everyone for input, especially to @andrewatfornax.