Hi,
We can fix things in release (vi hotfixs or directly) but the changes need to
be tested, develop is the best place to do that as that's what the CI runs off.
Last release we made changes in release and merge back to develop frequently.
Even if we didn't do this at some point you need to mer
ly let the dev branch unmerged as
it represents already what is released and the build version will keep its 0
value unchanged too.
-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com]
Envoyé : jeudi 5 septembre 2013 18:14
À : dev@flex.apache.org
Objet : Re: Nighly builds and
i [mailto:aha...@adobe.com]
>Envoyé : jeudi 5 septembre 2013 18:14
>À : dev@flex.apache.org
>Objet : Re: Nighly builds and releases
>
>
>
>On 9/5/13 3:23 AM, "Frédéric THOMAS" wrote:
>
>>After running sdk/ant, git status report only " flex-sdk-description.xm
2013 18:48
À : dev@flex.apache.org
Objet : Re: Nighly builds and releases
Maybe I'm not understanding the diagram on their page. To me there is a
line back from release branch to develop. It shouldn't have anything to do
with hotfixes, just bug fixes found and fixed after the release br
On 9/5/13 3:23 AM, "Frédéric THOMAS" wrote:
>After running sdk/ant, git status report only " flex-sdk-description.xml"
>as
>modified file, that's 5 months or so I didn't have a look in the SDK,
>could
>you tell me what should be done in order the build number be created only
>on
>the release bu
t it could introduce ?
-Fred
-Message d'origine-
De : Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Envoyé : jeudi 5 septembre 2013 11:47
À : dev@flex.apache.org
Objet : RE: Nighly builds and releases
Sorry for the delay, I was reading this before to go to sleep, it was more
than 5am so,
essage d'origine-
De : Justin Mclean [mailto:jus...@classsoftware.com]
Envoyé : jeudi 5 septembre 2013 05:10
À : dev@flex.apache.org
Objet : Re: Nighly builds and releases
Hi,
> That's here there is something I don't know, what should be merged
> back to the develop br
Hi,
> That's here there is something I don't know, what should be merged back to
> the develop branch ?
Changes would be made in the release branch and merged into develop, otherwise
the two branches would diverge and develop would no longer be a representation
of the last release. All of the CI
On 9/4/13 3:44 PM, "Justin Mclean" wrote:
>HI,
>
>> Are you sure this assertion is true for branches under development (dev
>>/
>> features or bugs).
>As part of the current release process, the release is tagged and then
>develop is merged into trunk, otherwise it would not be a true reflexion
e would fix on the RC, only this fix should be merged back or I'm
wrong ?
What else ?
-Fred
-Message d'origine-
De : Justin Mclean [mailto:jus...@classsoftware.com]
Envoyé : jeudi 5 septembre 2013 04:05
À : dev@flex.apache.org
Objet : Re: Nighly builds and releases
HI,
> Wha
HI,
> What was the problem exactly ?
One of the RCs had a build number of 0. The file in question was in gitignore
so the difference wasn't picked up until a RC had been made and several people
had tested it.
> why attributing a build number only at release time would make it harder
How do you
gine-
De : Justin Mclean [mailto:jus...@classsoftware.com]
Envoyé : jeudi 5 septembre 2013 03:15
À : dev@flex.apache.org
Objet : Re: Nighly builds and releases
Hi,
> I haven't look at how and when the date is added yet but can't we
> decide to add this date from the release ta
On Wed, Sep 4, 2013 at 11:15 AM, Erik de Bruin wrote:
> The job that creates the artifacts is simply running "ant super-clean
> release create-md5". It is not explicitly changing the filenames. I
> guess there is still something/somewhere left to update to "4.11.0"?
>
> EdB
>
>
I see that in flex
Hi,
> I haven't look at how and when the date is added yet but can't we decide to
> add this date from the release target only as the release target is supposed
> to be run on a release branch only ?
That could and has caused errors, one of the 4.10.0 RC had to be redone because
of this exact is
nvoyé : jeudi 5 septembre 2013 02:01
À : dev@flex.apache.org
Objet : Re: Nighly builds and releases
Hi,
If you can work out how to make a release than then do the merge without
merging the build number go for it.
You need to update this:
https://cwiki.apache.org/confluence/display/FLEX/Release+Guide+for+
Hi,
If you can work out how to make a release than then do the merge without
merging the build number go for it.
You need to update this:
https://cwiki.apache.org/confluence/display/FLEX/Release+Guide+for+the+SDK
Thanks,
Justin
of doing a
release branch, make the release into, so, it means as well adding the build
number.
-Fred
-Message d'origine-
De : Justin Mclean [mailto:jus...@classsoftware.com]
Envoyé : jeudi 5 septembre 2013 01:48
À : dev@flex.apache.org
Objet : Re: Nighly builds and releases
Hi,
>
Hi,
> Following nvie.com/posts/a-successful-git-branching-model/ the develop
> branch is never merged to the trunk but the release branch yes.
Yep that right, I've not had my coffee yet :-)
Same issue basically as the release branch is branched from develop, worked on,
tagged, released and the
ighly builds and releases
HI,
> Are you sure this assertion is true for branches under development
> (dev / features or bugs).
As part of the current release process, the release is tagged and then
develop is merged into trunk, otherwise it would not be a true reflexion of
what we actual
HI,
> Are you sure this assertion is true for branches under development (dev /
> features or bugs).
As part of the current release process, the release is tagged and then develop
is merged into trunk, otherwise it would not be a true reflexion of what we
actually released.
Can you see a better
Hi Justin,
Are you sure this assertion is true for branches under development (dev /
features or bugs).
-Fred
-Message d'origine-
De : Justin Mclean [mailto:jus...@classsoftware.com]
Envoyé : jeudi 5 septembre 2013 00:19
À : dev@flex.apache.org
Objet : Re: Nighly builds and rel
HI,
> We could change the build number back to 0 and only set the build number
> in the release branches.
I assume we talking about the build number in flex-sdk-description.xml?
The source code (in GIt) needs to reflect what we actually tag and release and
that includes the .xml files IMO.
Tha
The job that creates the artifacts is simply running "ant super-clean
release create-md5". It is not explicitly changing the filenames. I
guess there is still something/somewhere left to update to "4.11.0"?
EdB
On Wed, Sep 4, 2013 at 7:25 PM, OmPrakash Muppirala
wrote:
> On Wed, Sep 4, 2013 at
On Tue, Sep 3, 2013 at 5:54 PM, Justin Mclean wrote:
> HI,
>
> > The tracking is based on the Flex version. We dont make a distinction
> > between the nightly vs. released sdk. We should probably bump up the
> > version number in our develop branch to start tracking the nightlies.
>
> Were is it
On Wed, Sep 4, 2013 at 10:14 AM, Erik de Bruin wrote:
> The artifacts are simple copies of the output files in the workspace.
> If needed, we can add a copy and rename action to the 'release' job
> and create artifacts that fit your needs...
>
> EdB
>
Isn't the filename driven off of a propertie
The artifacts are simple copies of the output files in the workspace.
If needed, we can add a copy and rename action to the 'release' job
and create artifacts that fit your needs...
EdB
On Wed, Sep 4, 2013 at 7:01 PM, OmPrakash Muppirala
wrote:
> On Tue, Sep 3, 2013 at 5:54 PM, Justin Mclean w
ot git
>ignored today would not hassles any more at commit time after a build.
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com]
>Envoyé : mercredi 4 septembre 2013 18:02
>À : dev@flex.apache.org
>Objet : Re: Nighly builds and releases
>
>We cou
escription.xml which is not git
>ignored today would not hassles any more at commit time after a build.
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mercredi 4 septembre
>2013 18:02 À : dev@flex.apache.org Objet : Re: Nighly builds and
>
nvoyé : mercredi 4 septembre 2013 18:02
À : dev@flex.apache.org
Objet : Re: Nighly builds and releases
We could change the build number back to 0 and only set the build number in
the release branches.
On 9/4/13 5:01 AM, "Frédéric THOMAS" wrote:
>An option could be to add a checkbox label
feature, there will be a way to make a
>SNAPSHOT based on the user choice.
>
>-Fred
>
>-Message d'origine-----
>De : Justin Mclean [mailto:jus...@classsoftware.com]
>Envoyé : mercredi 4 septembre 2013 02:54
>À : dev@flex.apache.org
>Objet : Re: Nighly builds a
nd
indeed it is not documented.
Happily with the installer maven feature, there will be a way to make a
SNAPSHOT based on the user choice.
-Fred
-Message d'origine-
De : Justin Mclean [mailto:jus...@classsoftware.com]
Envoyé : mercredi 4 septembre 2013 02:54
À : dev@flex.apache.org
Objet
HI,
> The tracking is based on the Flex version. We dont make a distinction
> between the nightly vs. released sdk. We should probably bump up the
> version number in our develop branch to start tracking the nightlies.
Were is it pickup up the version from? The develop branch should have all
v
HI,
> I think it's too beneficial to everyone who wants to the bleeding edge to
> not have nightlies for testing and development.
Agree but we can't be providing it to SDK users as the latest release - it's
for development use only.
Justin
I think it's too beneficial to everyone who wants to the bleeding edge to
not have nightlies for testing and development. I'll agree we should just
post a "Here be Dragons" type caveat emptor.
-Mark
On Tue, Sep 3, 2013 at 8:25 PM, OmPrakash Muppirala wrote:
> A google search for "apache nightl
On Tue, Sep 3, 2013 at 5:30 PM, Justin Mclean wrote:
> Hi,
>
> Also noticed we don't seem to be tracking nightly build installs either?
>
> Justin
>
The tracking is based on the Flex version. We dont make a distinction
between the nightly vs. released sdk. We should probably bump up the
version
Hi,
Also noticed we don't seem to be tracking nightly build installs either?
Justin
A google search for "apache nightly build" shows me quite a few Apache
projects providing public links to nightly builds:
1. Solr: http://wiki.apache.org/solr/NightlyBuilds
2. JMeter: http://jmeter.apache.org/nightly.html
3. Direcory: http://directory.apache.org/studio/nightly-builds.html
4. N
On 9/3/13 5:09 PM, "Justin Mclean" wrote:
>Hi,
>
>An issue just come up on the incubator general list about nightly builds.
>[1]
>
>The installer lets you download the nightly build, and while convenient
>it looks like it's actually against Apache release guidelines [2]:
>"If the general public
Hi,
An issue just come up on the incubator general list about nightly builds. [1]
The installer lets you download the nightly build, and while convenient it
looks like it's actually against Apache release guidelines [2]:
"If the general public is being instructed to download a package, then that
39 matches
Mail list logo
