On 2/8/13 11:16 PM, Andrea Pescetti wrote:
On 06/02/2013 janI wrote:
I assume (without really knowing it) that there is an easy upgrade path
for extensions currently not being an oxt to become one. We need to
document (if not already done) this upgrade in a way, that motivates
the
extension
Jürgen Schmidt wrote:
it seems that nobody has stronger concerns against this proposal and I
think no vote is necessary. I will draft a blog and a mail to our
announce list that we will deprecate older package extensions with 4.0
and that we will support oxt packages only in the future.
You
On 06/02/2013 janI wrote:
I assume (without really knowing it) that there is an easy upgrade path
for extensions currently not being an oxt to become one. We need to
document (if not already done) this upgrade in a way, that motivates the
extension developers to do it.
Same for me: enforcing
Hi,
currently we can deploy many extension snippets, for example we can
deploy single xcu files, single jars, etc. All the single deploy units
that typically are packaged today in an oxt file with some further meta
data.
On the way to a cleaner and less complex extension deployment process I
+1
I assume (without really knowing it) that there is an easy upgrade path
for extensions currently not being an oxt to become one. We need to
document (if not already done) this upgrade in a way, that motivates the
extension developers to do it.
rgds
Jan I.
On 6 February 2013 17:04, Jürgen
