ProcessWire 2.3 Testing

[nikola]

Ryan, thanks for the answer. I've successfully updated the site from 2.2 to 2.3. It has lot's of articles (1000k+) and other pages including various page references. I've optimized the code through functions, solved some things that troubled me before with URL segments. The system has rewrite functionality for article URL's (I'm prepending categories and subcategories to article URL's and articles reside in one parent page) and so on...

All seems to work well, and faster then before   

[maniqui]

.maniqui: welcome to the forums and thanks for your feedback. I think Ryan has been experimenting with tags, but not yet fully in use. We are just learning Git

Thanks for the welcome, apeisa!

If you are experienced with git / github, it would be very valuable if you (and others of course) can shed a light how the ideal workflow with releases / tags should go.

I've some a fair amount of experience with Git, and I'll gladly shed some light.

Generally I don't add tags except when we need to link to something from the past. Since 2.3.0 is the current master, I didn't think it needed a tag yet. Though I was going to add it anyway once 2.3 is officially announced. 

Even if not officially announced (not sure what that means exactly), PW homepage already announces & offers to download PW 2.3.0, and it links to a zipball generated from master, as you mentioned. We could say tht PW 2.3.0 has already shipped.

Problem with saying that "2.3.0 is current master" is that master (the branch pointer) may move at any time, when further development (ie. probably a merge commit from dev) happens on it.

My suggestion is: tag the commit a8024bb as "2.3.0" and avoid any potential confusion, as may happen now between tags 2.2.9 and 2.2.9-final.

2.2.9.final was just to mark the spot where it was at before merging in the dev branch. I would have called it 2.2.10, except that I wanted 2.2.9 to be the last version number in the 2.2 version (since we'd used 2.2.10+ for dev branch). The 2.2.9 version that people have been installing is 2.2.9.final. For the most part you can ignore tags with ProcessWire, as we don't use them for anything other than making links to past things, when necessary. 

I consider that tagging each release is really helpful & useful for others (like, well, me) that have cloned/forked the repo & may need to checkout an old version to work with. Finding a merge commit from dev to master may be a hint that a new version may have been released, but really, it just too ambiguous, imho.  

But there is something that worries me a bit more... keep reading .

2.3.0 is the merge between branches dev and master. 

Problem is: there are 11 commits (including the 1 merge commit) that happened directly in branch master, 11 commits that were never merged back to branch dev.

Or, in other words, dev branch is currently missing 11 commits. 

I'd bet that wasn't intended (but correct me if I'm wrong), being that those 11 commits are part of both 2.2.9.final and 2.3.0 releases.

 

Proof of this is the current output (which shows the 11 commits missing from dev branch).

$ git log --graph --oneline --decorate dev..master  
* a8024bb (master) Merge branch 'dev'
* d453a76 (tag: 2.2.9.final) Enable the findPagesCode option in Inputfieldpage for non-Fieldtype context use of Inputfield forms (like FormBuilder)
* 9b3039d Fix issue with RepeaterPageArray lacking a makeNew() method.
* e1c66b3 Update FieldtypePage to support setting by strings like $page->someField = "123|456|789";
* 3a76113 Fix non UTF-8 encode on InputfieldCommentsAdmin cite line
* c3334a7 Fix issue with InputfieldCommentsAdmin not working with open/close of individual comments in the page comment editor
* 3386764 Fix issue with InputfieldSelect.module that was appearing on select fields with Form Builder forms.
* c8e832d Update InputfieldMaxWidth to be 100% rather than 99%. Add isNew reserved word to core/Fields.php.
* ac24667 Minor fix to InputfieldCheckbox.module
* 9b796be Fix InputfieldCheckbox so that it displays proper label (rather than value)
* e937903 (tag: 2.2.9) Fix issue with InputfieldRepeater 'add item' giving a JS error in some cases.

To get out of this situation, one solution (probably the most correct one) is to merge branch master back to branch dev.

These are the steps:

$ git tag -a 2.3.0 master # As suggested previously, add the corresponding release tag
# Alternatively, you could do: "git tag -a 2.3.0 a8024bb"
# as a8024bb is less ambiguous, as it is the commit corresponding
# to the 2.3.0 release (the current tip of master branch)

$ git checkout dev # Switch to dev branch

$ git merge master # Merge master branch into dev branch
# Alternatively, if you tagged the master branch as suggested, you could do: "git merge 2.3.0"

That will create a merge commit and then, the 11 missing commits will now be part of the dev branch, putting PW development back on track.

Please, don't hesitate in getting back to me or reaching me at #processwire on irc.freenode.net (my nickname there is Mannequin).

[ryan]

Maniqui,

Thanks for your suggestions. Regarding the missing commits, it appears that GitHub is not giving the correct information about this, or maybe I'm misunderstanding. All of those updates are on both branches. I went through each of the items to confirm. As an example, look at the second one 9b3039d which says "Fix issue with RepeaterPageArray lacking a makeNew() method." But I can go and see that this was updated on both branches: master and dev. The same goes for all the other updates. Let me know if I'm missing something. 

My suggestion is: tag the commit a8024bb as "2.3.0" and avoid any potential confusion, as may happen now between tags 2.2.9 and 2.2.9-final.

I will go ahead and tag it 2.3.0 here. But I'm not sure this would have resolved the 2.2.9 and 2.2.9-final, because I didn't realize 2.2.9 had commits after the original tag until I was merging in 2.3. I honestly don't know what happened there, but probably some workflow/user error on my part. What would have solved it here is if I had another component to the version number so that the dev branch could have an incrementing version that didn't potentially conflict with a master version. That way someone could say, I'm running 2.3.0.3  or "2.3.0 dev 3" and I know by that extra "3" at the end that it's a dev branch revision. Then once ready to merge to master, it would become 2.3.1 on master and 2.3.1.0 in dev. This seems like a workable route to me, but let me know if you can think of a better route?

[maniqui]

Ryan, thanks for the prompt reply.
 

Maniqui,
 
Thanks for your suggestions. Regarding the missing commits, it appears that GitHub is not giving the correct information about this, or maybe I'm misunderstanding. All of those updates are on both branches. I went through each of the items to confirm. As an example, look at the second one 9b3039d which says "Fix issue with RepeaterPageArray lacking a makeNew() method." But I can go and see that this was updated on both branches: master and dev. The same goes for all the other updates. 
 
Let me know if I'm missing something.

 
It seems both of us are right.
From a ProcessWire codebase point-of-view, you are right: almost all the code written (added/removed) on those 11 missing commits is already on dev.  I say almost because there are 3 lines of code introduced in master that are still missing in dev, as you can see below.
 

$ git diff dev...master 
diff --git a/wire/modules/Fieldtype/FieldtypePage.module b/wire/modules/Fieldtype/FieldtypePage.module
index 06e0f65..c5e2669 100644
--- a/wire/modules/Fieldtype/FieldtypePage.module
+++ b/wire/modules/Fieldtype/FieldtypePage.module
@@ -254,6 +254,9 @@ class FieldtypePage extends FieldtypeMulti {
                } else if(ctype_digit("$value")) {
                        // page ID
                        $result = $this->pages->get("id=" . $value); 
+               
+               } else if(strpos($value, '|') !== false && ctype_digit(str_replace('|', '', $value))) {
+                       $result = $this->pages->getById(explode('|', $value)); 

                } else if(strpos($value, '|') !== false && ctype_digit(str_replace('|', '', $value))) {
                        // CSV string separated by '|' characters

So, again, you are correct: at some point, probably by copy-pasting chunks of code, you introduced into dev the pieces of code (the changes) on those 11 commits. 
A proof of that is that the changes introduced in commit 9b3039d (an atomic change, only present in master) are also part of commit 7dab612, which is a huge commit in dev. 
It's almost as if you cherry-picked (see git cherry-pick) but in a manual, human, untidy way.
So far, so good. And the only changes you missed to move manually are those shown on the git diff output above.  
 
From a Git point-of-view, I'm right: 11 commits done in master aren't part of the dev branch. 

Even Github shows that same info here (dev is 11 commits behind and 4 ahead of master) and here (comparing both branches, it shows the same diff as above).

Technically speaking, from a Git point-of-view, master and dev have diverged.

So, now that we all have a better understanding of what happened and what is missing from dev branch (just 3 lines of code), let me suggest what would have been better options to bring the changes from those 11 commits in master branch back to dev branch. As said, Ryan, you did it manually, but that's prone to (human) errors, as changes could be missed and/or introduced with errors.

First (best) option: as suggested on previous post, just merging master (righ now, or back at the time when you did those 9 commits now known as "2.2.9.final") back to dev is all that's needed.

Right now, that action will just bring to dev those 3 lines of code missing, by creating a merge commit. In the graph, it will clearly show that those commits are part of dev and there won't be any doubt.

Back at that time, that action would have bring the many lines of code missing, releasing you from the task (human & prone to errors) of manually having to copy-paste them.  

Second option: git cherry-pick. Right now, this option won't make sense, as you already "cherry-picked" the changes from master back to dev in a human fashion. Back at that time, if for some reason (I can't think of one) you couldn't merge master back to dev, git cherry-pick would have been the best option, as it lets you manually pick which commits from master you would like to re-apply to dev. Take into consideration that cherry-picking commits from a branch (ie. master) creates new commit objects on the destination branch (ie. dev). A commit created by a cherry-pick will have a different hash than the original commit (the one cherry-picked), but it will introduce the same exact set of changes (ie. the same +/- patches).

Bottom line: while standing on dev branch run "git merge master" and call it a day.

I will go ahead and tag it 2.3.0 here. But I'm not sure this would have resolved the 2.2.9 and 2.2.9-final, because I didn't realize 2.2.9 had commits after the original tag until I was merging in 2.3. I honestly don't know what happened there, but probably some workflow/user error on my part. What would have solved it here is if I had another component to the version number so that the dev branch could have an incrementing version that didn't potentially conflict with a master version. That way someone could say, I'm running 2.3.0.3  or "2.3.0 dev 3" and I know by that extra "3" at the end that it's a dev branch revision. Then once ready to merge to master, it would become 2.3.1 on master and 2.3.1.0 in dev. This seems like a workable route to me, but let me know if you can think of a better route?

Mmmmm.

Personally, I'll suggest to stay with the "dev" name for the development branch. Something you could do is that, after some release (ie. 2.3.0), on the next commit, on some project file (ie. readme.txt, or changes.txt, or version or whatever you use) you rename the version to 2.3.1-dev. In this example, it's important to get that "2.3.1-dev" means "the development done for next 2.3.1 version", and not "the development done after 2.3.1 release".

Then, on some place of the PW admin, you could print "ProcessWire (2.3.1-dev)". But the question remains: at which exact commit of the many commits that may correspond to the development of 2.3.1 is this PW installation standing at? 

I'm not sure what's the answer for this, but Git may be helpful here. There is the git describe with "shows the most recent tag that is reachable from a commit".

For example, if in your PW repo you run:

$ git describe master 

You will get this output:

2.2.9.final-174-ga8024bb

Which means that master branch is 174 commits above the "2.2.9.final" tag, more precisely in the commit a8024bb. The "g" is just a prefix to indicate that is a commit done in Git.

So, as you can see, there is a good way to describe where is standing someone in relation to last tagged version.

Ryan, 2 last things:

First, as you are the BDFL and main commiter of ProcessWire, I'd suggest you to begin using annotated tags:

http://git-scm.com/book/en/Git-Basics-Tagging#Annotated-Tags

Second, I'd suggest taking a peek at this Git branching model:

http://nvie.com/posts/a-successful-git-branching-model/

It's a pretty popular one, and it may fit into the way PW is currently being developed. Even if you don't want to follow that (or any other) particular branching model, the article is pretty good to clear up some concepts.

That's all by now, thanks for reading.

[apeisa]

Thanks maniqui, that is very helpful for us git toddlers here. Learned a lot!

[ryan]

Thanks Maniqui, this is great info! You are officially our Git advisor, should you choose to accept the job.

From a ProcessWire codebase point-of-view, you are right: almost all the code written (added/removed) on those 11 missing commits is already ondev.  I say almost because there are 3 lines of code introduced in master that are still missing in dev, as you can see below.

Actually those 3 lines aren't supposed to be in dev OR master. It appears to be just a duplicate if() statement to the one right below it. It doesn't appear to be a problem, but of course it's unnecessary redundant code. So I will have to remove this from master. I actually have no idea why or how there are duplicate lines there. But thank you for finding it. 

Great links too, bookmarked and look forward to reading. 

[maniqui]

Thanks Maniqui, this is great info! You are officially our Git advisor, should you choose to accept the job.

I'll gladly accept it and help the community whenever I can. As said before, you can find me at #processwire at irc.freenode.net 

[patzer]

A big +1 for using meaningful tags. I'm importing ProcessWire into a project as a git submodule, and those work by referencing a specific commit (or, better yet, tagged commit). Thanks!

[Arcturus]

The link on the homepage says version 2.3.0 and then takes you to a zip file saying 2.2.9. If that isn't an error, it's at least confusing.

[Soma]

The link on the homepage says version 2.3.0 and then takes you to a zip file saying 2.2.9. If that isn't an error, it's at least confusing.

From in this thread http://processwire.com/talk/topic/2768-processwire-23-testing/?p=30475

[roy]

When unzipping 2.2.9.final there is a password request for several files

[Soma]

Hi roy, there's no password protection for any files in PW. Can you tell a little more what you're experiencing?

[roy]

Hi Soma,

I made a screenshot yesterday:

http://imgur.com/rRzTZu4

I have this issue with the download option/file on:

http://processwire.com/download/

file:

https://github.com/ryancramerdesign/ProcessWire/zipball/master

The file on the homepage doesn't have this problem.

[ryan]

Roy I think something may be amiss with the file you downloaded, or with whatever program is unzipping it. 

Also, the link you mentioned is to 2.2.9. Be sure you are grabbing 2.3.0, which is linked from the homepage. GitHub keeps changing the ZIP download URL, so I had to update it yet again as recently as yesterday (this time replacing /zipball/ with /archive/).  

[diegonella]

PW is excellent.

When you install the version 2.3 (new installation) float fields not showing decimal me, someone had the same problem?

[ryan]

When you install the version 2.3 (new installation) float fields not showing decimal me, someone had the same problem?

What are your settings for the field? Double check that you've defined the float precision. 

[BillyKoch]

I just did the latest install on an Arvixe Windows Hosting IIS 8.0 - so far it looks like it is working okay.  Still more testing to come.

I take that back..lol!

[nfil]

Hello.

I don't know if this could this be added on the Page Name module's settings to PW installation:

ã õ 

I added those two because I use portuguese to generate FURLS and I noticed that on PW 2.3 . Don't know if this is relevant or not. Thank you.

ä=a

ã=a

õ=o

ö=o

...

[yellowled]

Fresh install on PHP 5.4.16 (not sure about the exact Apache 2/MySQL 5 versions, let me know if those would be important). Worked like a charm. Had to explicitly set the RewriteBase to "/", but that's always been necessary on this server.

The dev version identifies itself als ProcessWire 2.3.5, is that even the right one? (Downloaded the zip from the dev tree on GitHub.)

[ryan]

Thanks for testing it out. 2.3.5 is the current dev branch version (soon to be 2.3.6)

[Adam Kiss]

Ryan, how can I leverage (what I assume) stable version of Language Support – Page Names from dev? Should I just drop /wire/modules/LanguageSupport from dev branch to production?

Thanks

[ryan]

Adam, the LanguageSupport modules can't be pulled from dev and put into another version. There are many upgrades to the dev core in order to support the features of LanguageSupport. The LanguageSupport modules wouldn't work if you tried to take them from the dev version and use them in an older version of PW. If you want the features provided by the latest LanguageSupport modules, the best route is just to use dev. If you find it to be stable for your site's needs, then you should feel comfortable that it'll be as stable as the actual 'stable' branch. Just test thoroughly. The main thing you have to pay more attention with on dev is when upgrading from stable to dev or from dev to dev–you just want to test a little more than if you were upgrading from stable to stable. But once you have it up and running, you can generally expect the stability to be the same as the stable branch. 

[Adam Kiss]

So if I want to use stable Localized page names (mind you, not latest, but stable and ready for production), I should go for the dev, right? (2.3.0 has localized page names marked as 0.0.3 – not Ready f/ Production)

[ryan]

The LanguageSupportPageNames on dev core (2.3.5) is much farther along (and more stable) than the one on stable core (2.3.0). If you want multi-language support, you would benefit a lot from using dev. There are still bugs being worked out here, but most of them are ones that only affect Soma and his advanced usages but they are all issues that will be fixed before dev becomes the stable 2.4. 

[nfil]

Fresh install on PHP 5.4.16 (not sure about the exact Apache 2/MySQL 5 versions, let me know if those would be important). Worked like a charm. Had to explicitly set the RewriteBase to "/", but that's always been necessary on this server.

The dev version identifies itself als ProcessWire 2.3.5, is that even the right one? (Downloaded the zip from the dev tree on GitHub.)

Thanks for the reminder.

The LanguageSupportPageNames on dev core (2.3.5) is much farther along (and more stable) than the one on stable core (2.3.0). If you want multi-language support, you would benefit a lot from using dev. There are still bugs being worked out here, but most of them are ones that only affect Soma and his advanced usages but they are all issues that will be fixed before dev becomes the stable 2.4. 

So we can start developing a production site on dev 2.3.5 and when 2.4 stable version is released, we can upgrade it.

Just had doubts on a website that will need the http://store.di.net/collections/software/products/processwire-form-builder

Can we use the module  ProcessWire Form Builder now on dev 2.3.5 and it will work when we upgrade to 2.4 stable?

Thank you.